Document project management workflows in GitHub #4388
Conversation
| @@ -1,58 +1,61 @@ | |||
| # Developer Contributor Guide | |||
| # Contributor Guide | |||
There was a problem hiding this comment.
There is another document somewhere for general non-dev contributing too. And this is very developer focussed, so this should probably be the dev contributor guide
| - `web/feature/avatar-component` | ||
| - `backend/bugfix/email-html-escaping` | ||
| 3. Work on the new branch, feel free to commit regularly. Ideally a commit should make one change to the code but the code should compile and run both before and after the change (though this is not always possible). Each feature or bugfix should be self-contained and if possible, split a change up into multiple smaller PRs so they're easier to review. | ||
| 4. Push the new branch to GitHub, and open a Pull Request (PR). If your branch is ready to be merged, pending review, make it a normal PR. If it's still work in progress and you don't want a review yet, you can make it a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/). Choose some appropriate labels on the PR, such as `web`/`backend` and `feature`/`bug` to make it easier for others to navigate the list of PRs. | ||
| 4. Push the new branch to GitHub, and open a Pull Request (PR). If your branch is ready to be merged, pending review, make it a normal PR. If it's still work in progress and you don't want a review yet, you can make it a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/). Choose some appropriate labels on the PR, such as `web`/`backend` and `feature`/`bugfix` to make it easier for others to navigate the list of PRs. |
There was a problem hiding this comment.
I think the label is called "bug"
|
|
||
| We collaborate on code through git, hosted on GitHub. If you are a software engineer (web/mobile/backend), you should request write access to the codebase. | ||
| Couchers.org is currently split into teams, among them: product (divided into backend, web, mobile, and devops), design, community, marketing, and support and moderation. |
There was a problem hiding this comment.
There is no mobile team at the moment
| If you are looking for something to help with, have a look at the open issues! They are sorted by tags to help with filtering. Here are some examples: | ||
| If you are a new contributor, we recommend starting with a [good first issue](https://github.com/orgs/Couchers-org/projects/4/views/6?sliceBy%5Bvalue%5D=good+first+issue) and then a [good second issue](https://github.com/orgs/Couchers-org/projects/4/views/6?sliceBy%5Bvalue%5D=good+second+issue). Otherwise, please look at [current open tasks](https://github.com/orgs/Couchers-org/projects/4/views/3?sliceBy%5Bvalue%5D=_noValue) or even [next sprint's open tasks](https://github.com/orgs/Couchers-org/projects/4/views/9?sliceBy%5Bvalue%5D=_noValue) if nothing is currently open. When you find a task you want to work on, leave a comment saying the same and assign the task to yourself. | ||
|
|
||
| ## Detailing a task |
There was a problem hiding this comment.
I think this section is great, but I feel it might seem like a lot of process for someone who is new to contributing to the project. Maybe we can move it further down and/or do something else to make it clear that one doesn't have to go through the this whole part to push through their first issue? What do you think?
|
|
||
| ## Project Management | ||
|
|
||
| Couchers contributions are managed by all teams collectively within the [GitHub Project](https://github.com/orgs/Couchers-org/projects/4). Product development is done in pursuit of quarterly release milestones by which the team strives to release platform features and content relevant to our primary objectives. Consistency and focus is maintained through Scrum-style development cycles every month during which we develop, assess, plan, and repeat both asynchronously and in weekly discussion meetings. |
There was a problem hiding this comment.
Couchers contributions are managed by all teams collectively
Teams other than dev have not historically used github. Though I would like that to change going forward, I think we can accept being a "software non-profit" that coordinates here.
Re: the next sentence. I think working around quarterly release milestones (aka a blog post with some updates and using that as a deadline) might be a good way to go. I'm not sure if "Scrum-style" is accurate, maybe we should call it just "Scrum-inspired", though I've never been in a team where "Scrum" really meant so much.
Let's discuss this in the upcoming meeting!
Closes #4385
Will be going over this in the 5/28 meeting