First approach to Github Projects guidelines documentation #29
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,48 @@ | ||
| # Guidelines for our GitHub projects | ||
|
|
||
| In this place we will have the documentation for how to handle issues | ||
| among projects of **TecnoYucas**. | ||
|
|
||
| ## General notes | ||
|
|
||
| ### Some rules first about the project | ||
|
|
||
| 1. Every repo must have a automatic Kanban-like GitHub project | ||
| 2. Every single pull request MUST be associated with a GitHub issue | ||
| 3. Whenever you close a pull request or comment on an issue, please | ||
| make sure to agree on issue completion. | ||
| 4. All issues should have a deliverable product (a document or a | ||
| merged branch, this would help on issue completion agreement). | ||
|
|
||
| ### Some recommendations | ||
|
|
||
| - Keep language as complete and concise as possible. | ||
| - Use Todo lists (this can help to better define the scope of an issue | ||
| and the state of it). | ||
| - Please try not to create huge issues, make them as short and clear | ||
| scoped as possible. If you need some sort of complex issue, please | ||
| break it down into smaller pieces. | ||
|
|
||
| ### The workflow | ||
|
|
||
| 1. When an issue is newly created, it will directly go into `Inbox | ||
| (Not approved yet)` column | ||
| 2. After an issue is approved (by at least **two** members of the | ||
|
There was a problem hiding this comment. we can automate this if we use waffle instead of github projects and treat the boards to use labels, so an issue can go from Inbox to There was a problem hiding this comment. Cool, I can investigate and set a project in Waffle, what do you think @sadasant ? There was a problem hiding this comment. I haven't used Waffle, but Github Projects have something similar: https://help.github.com/articles/configuring-automation-for-project-boards/ There was a problem hiding this comment. Yes! Well, essentially: all of the columns should be automated based on tags, once we do that, I'll be comfortable with having rules around this. None of this process should be manual (except for some of the issue assignment at least) |
||
| team), the issue can be manually moved into `To do (Approved)` | ||
| column and it is ready to be started. | ||
| 3. The asignee should be the only one to move an issue from `To do | ||
| (approved)` to `In progress` column | ||
| 4. After an issue is considered done, it must be closed and it | ||
| will be automatically moved to `Done` column. | ||
| 5. If an issue is reopened, it will go into `In progress` column. | ||
|
|
||
| ### Recommendations on completion agreement | ||
|
|
||
| Completion agreement is what makes an issue defined as completed. | ||
|
|
||
| - Issues descriptions should carry a definition of done | ||
| - An issue should be considered done with the approval of at least | ||
| **two** members of the team. | ||
| - Use tags to determine whether an user have reviewed an issue | ||
| (this user MUST add the tag. Every single reviewer should have | ||
| a tag) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not consistent with our current
DO NOT REMOVEissues. Let’s rephrase this to be relative to the Publication-N repos and not the meta repo.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sadasant When I say "deliverable product", I mean, a generic way to give a "tangible" solution for an issue, the issue could be related or not to a publication. For example, this is not a document considered as TecnoYucas publication, therefore, it is just a guideline document, a "deliverable product" of this issue. What I can do is to put a note that states that a "Deliverable product" could also be a Publication-N.
I am guessing TecnoYucas will be wider than just publications. We will be doing things not related to publications. For example: A merged feature, is a "deliverable product" of an issue but as you know, it does not have necessarily be a publication-related issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I understand that, I think. However, we have created issues that have no deliverables, which are our DO NOT REMOVE issues. We use them as a place to communicate. These issues were created with the goal of not removing them for now. What are your thoughts around that?