Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A way to verify everyone who is running OpenHack events has access to this repo #59

Open
qrush opened this issue Nov 21, 2012 · 6 comments

Comments

@qrush
Copy link
Member

qrush commented Nov 21, 2012

So we have a problem:

People running OpenHack can't always update the website. I don't want to have to manually approve each copy/edit change (and no one really should have to) once a city has been merged in.

I think we should have a separate repo to fix this that can:

  1. Verify committers on the repo have read/write permissions
  2. Add a new city and any committers
  3. Periodically check that everyone has access

Maybe we can have an OpenHack sub? https://github.com/37signals/sub

Any other thoughts?

@jcaudle
Copy link
Contributor

jcaudle commented Nov 21, 2012

I like the idea of an OpenHack sub, but I'm curious what sorts of commands would be there. Would it be primarily for managing the committers?

It might also be a good idea to include a CONTRIBUTING.md file to explain the expectation that once someone is granted access to the repository, they should update their own page as needed.

@ilikepi
Copy link
Member

ilikepi commented Nov 27, 2012

If the suggested sub was intended to manage committers, does it make sense to try to add access management functionality to hub, since the framework for conversing with the GH API is already built in that project? Perhaps then it would be relatively simple to build an OpenHack-specific tool by piggybacking on hub.

As an aside, I agree it would be helpful to have basic contributor guidelines specified somewhere. Seems like it might be useful to open a separate issue for discussing that if discussion is warranted.

@qrush
Copy link
Member Author

qrush commented Jan 31, 2013

Bumping this, we need a better way for this to happen. We shouldnt have to merge PRs to allow dates to update.

Maybe everyone should have push, pull, admin rights on this repo?

@jdiago
Copy link
Contributor

jdiago commented Jan 31, 2013

When Miami got added, I also got added into a Miami team in the OpenHack org that has push/pull permissions. Is there a way to automate that?

@qrush qrush mentioned this issue Feb 20, 2013
@dideler
Copy link
Contributor

dideler commented Sep 2, 2014

I'm not sure if this issue is about how to give those who run OpenHack events access to this repo, or how to verify those people before adding them to the trusted group.

Based on #59 (comment), I assume there are teams (with push permissions) within the organization to add trusted organizers to. So the issue would be how do you conveniently verify these people before adding them to the appropriate team. Is this step being done manually, and if so, is it too difficult or time consuming?

@qrush
Copy link
Member Author

qrush commented Sep 2, 2014

There is no way of automating this right now and sadly github teams aren't
public. If someone wants to take this over and figure out a way to automate
both managing this and making the teams public, that would be helpful.

On Tue, Sep 2, 2014 at 7:29 AM, Dennis Ideler notifications@github.com
wrote:

I'm not sure if this issue is about how to give those who run OpenHack
events access to this repo, or how to verify those people before adding
them to the trusted group.

Based on #59 (comment)
#59 (comment),
I assume there are teams (with push permissions) within the organization to
add trusted organizers to. So the issue would be how do you conveniently
verify these people before adding them to the appropriate team. Is this
step being done manually, and if so, is it too difficult or time consuming?


Reply to this email directly or view it on GitHub
#59 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants