-
Notifications
You must be signed in to change notification settings - Fork 226
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
Access to Repos? #23
Comments
On Mon, Jun 01, 2015 at 07:44:38PM -0700, Juan Batiz-Benet wrote:
Tightly-scoped commit access makes sense to me, especially since it The only concern I have is with Waffle, because you can't move cards |
@wking I thought this at first -- was trying to move a card for ipfs/ipfs-webui#56 in https://waffle.io/ipfs/ipfs but I only have write access to ipfs/webui so I could not move it. However I tried going to https://waffle.io/ipfs/webui and I could indeed move the card, and of course the change is reflected in the other board as well. https://waffle.io/ipfs/webui does not have all the same columns as the main waffle board, but it could. Not the ideal workflow, but works in the current constraints. |
@harlantwood also if you assign the label by hand in the repo, waffle will pick it up too. sorry the waffle board permissions are annoying. mind pointing this out to the waffle team? |
On Tue, Jun 02, 2015 at 03:48:08PM -0700, Harlan T Wood wrote:
I reported that earlier and it's waffleio/waffle.io#1902. My concern |
i'll close this for now. comment + reopen if this becomes an issue |
@jbenet @wking I ran across this when looking through our own Waffle board and wanted to offer two options. The first -- would it be possible to create an Issues Only repository? (ie ipfs/ipfs-issues)? You could grant collaborator access pretty leniently (or maybe even write a script to add anyone who forks the repo as a collaborator, though that might be living on the edge. :)) I've wondered if this could be a solution for cases like your's, and if not, why? (So we can continue to think about how to best solve this problem.) The other option would be to encourage your contributors to issue pull requests as soon as they start work. If they issue pull requests cross-referencing the original issue (ie: fixes ipfs/ipfs#32), Waffle will visually connect the pull request beneath the issue, even if issued from a fork (as long as the cross-repo reference exists!) The title or description could also include a note like "work started" which would cue a collaborator to pull that issue in progress if they feel like the contributor is reliable and most likely making decent progress on the issue. Curious to hear what you think? Ashley |
Hey @ashumz! thanks for dropping by
It would not work for us to have one repo for issues. separate issues is often why it makes sense to split repos-- easier to maintain + figure out problems. I'm not sure how well things are working out atm on this front -- but maybe others can comment. |
So far we've been granting collab access to repos to whoever has been collaborating for a while, and then requests it. I'd love to keep doing that per repo, that way we can scope access (e.g. go-ipfs collabs cant impact node-ipfs collabs) and sub-cultures and ways of working can be independent. this is perhaps important because different projects (and languages!) have different cultural collaboration styles/rules.
Basically, if you want access to a repo, ask me for it and you'll likely get it (except maybe a few repos)
If this is annoying to people though, can consider one big org where everyone has R/W on everything, except a few "for release" repos that we PR into for code that ships (because at some point released code will have to be security audited, etc). open to discussion on all this.
The text was updated successfully, but these errors were encountered: