NealHumphrey
commented
7 years ago A couple work arounds that help this issue:
- Use an onboarding survey at the beginning of the process, to get their contact information. Make one of the survey questions the url of their fork, forcing them to adopt the fork workflow.
- In both DCAF and Housing Insights, onboarding instructions include how to set up two remote repositories (i.e. the fork and the codefordc repo)
- Onboarding instructions also include
git remote set-url --push upstream no-pushwhich overwrites the url so that attempts to push to the team repo will fail. - Add no-push protection to dev and master branches via Github settings to prevent accidental pushing from anyone that didn't do the set-url step.
Just an idea here to consider (maybe include in the project roundtable discussion). One of the pain points for me as a project manager is assigning people to issues on Github so that I know who's working on what, especially when new people join the project. Github is partly to blame for this.
1) I need a new user's Github username 2) I need to manually add them as a collaborator to the project. 3) They need to accept the invite. 50% of the time I need to remind them because they didn't see the invite (usually because they've changed their email settings to not get a notificiation) 4) Only after they've accepted the invite does Github allow me to add them as an 'assignee' 5) I have to give them write access to the repository for them to actually be listed as an assignee and edit our issues - it is not possible to separate 'issues' permissions from repo permissions. I have protection on dev and master branches so this isn't too big, though I'd rather have them only write to their fork.
These barriers mean that often I coordinate with someone to start working on an issue when they join the project, but I can't note on the issue that they are actually assigned to the issue until all the above is resolved.
According to this help article, I'm also allowed to allocate assignees to "members of your organization with read permissions on the repository." What if people everyone that came to Code for DC was added as a member of the Code for DC organization? They could be given read-only permissions to all the repos (it's all public anyways), and that way they could be assigned to issues right away. We could automate this the way we automate the 'join slack' function (probably making the 'join slack' form into a 'join code for dc' form).