这是一个创建于 3486 天前的主题，其中的信息可能已经有所发展或是发生改变。
GitLab Workflow
1.Alwayscreatean issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
2.'Double link'issues to prevent internal confusion and us failing to report back to the reporters. For example, open an issue with link to ZenDesk and close the issue with copy of the response. Or add 'Report: ' lines to the description with links to relevant issues and feature requests and ensure they are closed and note this with a comment. If you are not responsible for reporting back please do not close an issue, instead reassign it.
3.If issues are related,crosslinkthem (a link from each issue to the other one). Put the links at the top of the issues' description with a short mention of the relationship (Report, etc.). If there are more than 2 issues, use one issue as the central one and crosslink all issues to this one. Please, also crosslink between ZenDesk and GitLab issues.
4.After a discussion about a featureupdate the issue bodywith the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
5.Give the community thechance to help. For example: place issues on the feedback tracker, leave comments in rake check tests about what you can run manually and ask 'Can you send a merge request to fix this?'.
6.Submit thesmallestitem of work that makes sense. When creating an issue describe the smallest fix possible, put suggestions for enhancements in separate issues and link them. If you're new to GitLab and are writing documentation or instructions submit your first merge request for at most 20 lines.
7.Do not leave issues open for a long time, issues should beactionableand realistic. If you are assigned but don't have time, assign it to someone else. If nobody is assigned and it is not a priority, please ensure the community can help and close it.
8.Make a conscious effort toprioritizeyour work. The priority of items depends on multiple factors: is there a team member waiting for the answer, what is the impact if you delay it, how many people does it affect, etc. This is detailed inthe development workflow document.
9.Use the public issue trackers on GitLab.com for everything sincewe work out in the open. We do still use some private issue trackers on our internal dev.gitlab.org server, such as fororganizationalissues that do not have a home in one of the public team trackers that can be found on theteam structurepage.
10.Pick issues from the currentmilestone.
11.We try not to assign issues to people but to have peoplepick issuesin a milestone themselves.
12.Assign an issue to yourself as soon as you start to work on it, but not before that time. If you complete part of an issue and need someone else to take the next step,re-assignthe issue to that person.
13.When reassigning an issue, make sure that the issue body contains the latest information. The issue body should be thesingle source of truth.
14.We keep ourpromisesand do not make external promises without internal agreement.
15.Even when something is not done, share it internally so people can comment early and prevent rework. Mark the merge requestWork In Progressso it is not merged by accident.
16.When you create a merge request,mentionthe issue(s) that it solves in the description. If any followup actions are required on the issue after the merge request is merged, like reporting back to any customers or writing documentation, avoid auto closing it by sayingFixes #1orCloses #1.
17.Once a merge request is created, make sure to assign it to the proper person:
1.For example a merge request that fixes a frontend issue should have theFrontendlabel and be assigned to a Frontend Engineer for review. For other workflow labels please seePROCESS.md.
2.A merge request that is related to Continuous Integration should be assigned to the GitLab CI lead.
3.All other merge requests should be assigned for review to either a merge request miniboss or endboss. You can find the people with these roles on theteam page.
4.Once a merge request has gone through review by a miniboss, they will assign it to an endboss who will do a final review and perform the actual merge if satisfied.
18.Whenyouare done with your merge request, remove the WIP prefix andassignthe merge request to someone to review and merge it. You can still make changes based on feedback of course, but by removing the WIP prefix it clarifies when the main body of work is completed.
19.When a merge request is done, set milestone to the version it should be included in.
20.If you are assigned to review and merge a merge request and would like the creator to make somechanges, comment on the merge request and assign it back to the creator. When they have addressed the concern, they will reassign it to the reviewer.
21.If you are assigned to merge a merge request and there is amerge conflict, consider trying to resolve ityourselfinstead of asking the MR creator to resolve the conflict. If it is easy to resolve you avoid a round trip between you and the creator, and the MR gets merged sooner. This is a suggestion, not an obligation.
22.If you ask a question to a specific person, always start the comment by mentioning them; this will ensure they see it if their notification level is mentioned and other people will understand they don't have to respond.
23.Do not close an issue until it is fully done, which means code has been merged, it has beenreportedback to any customers and the community, all issue trackers are updated and any documentation is written and merged.
24.Whenclosingan issue leave a comment explaining why you are closing the issue.
25.If a user suggests an enhancement, try and find an existing issue that addresses their concern, or create a new one. Ask if they'd like to elaborate on their idea in one of these issues.
1.Alwayscreatean issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
2.'Double link'issues to prevent internal confusion and us failing to report back to the reporters. For example, open an issue with link to ZenDesk and close the issue with copy of the response. Or add 'Report: ' lines to the description with links to relevant issues and feature requests and ensure they are closed and note this with a comment. If you are not responsible for reporting back please do not close an issue, instead reassign it.
3.If issues are related,crosslinkthem (a link from each issue to the other one). Put the links at the top of the issues' description with a short mention of the relationship (Report, etc.). If there are more than 2 issues, use one issue as the central one and crosslink all issues to this one. Please, also crosslink between ZenDesk and GitLab issues.
4.After a discussion about a featureupdate the issue bodywith the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
5.Give the community thechance to help. For example: place issues on the feedback tracker, leave comments in rake check tests about what you can run manually and ask 'Can you send a merge request to fix this?'.
6.Submit thesmallestitem of work that makes sense. When creating an issue describe the smallest fix possible, put suggestions for enhancements in separate issues and link them. If you're new to GitLab and are writing documentation or instructions submit your first merge request for at most 20 lines.
7.Do not leave issues open for a long time, issues should beactionableand realistic. If you are assigned but don't have time, assign it to someone else. If nobody is assigned and it is not a priority, please ensure the community can help and close it.
8.Make a conscious effort toprioritizeyour work. The priority of items depends on multiple factors: is there a team member waiting for the answer, what is the impact if you delay it, how many people does it affect, etc. This is detailed inthe development workflow document.
9.Use the public issue trackers on GitLab.com for everything sincewe work out in the open. We do still use some private issue trackers on our internal dev.gitlab.org server, such as fororganizationalissues that do not have a home in one of the public team trackers that can be found on theteam structurepage.
10.Pick issues from the currentmilestone.
11.We try not to assign issues to people but to have peoplepick issuesin a milestone themselves.
12.Assign an issue to yourself as soon as you start to work on it, but not before that time. If you complete part of an issue and need someone else to take the next step,re-assignthe issue to that person.
13.When reassigning an issue, make sure that the issue body contains the latest information. The issue body should be thesingle source of truth.
14.We keep ourpromisesand do not make external promises without internal agreement.
15.Even when something is not done, share it internally so people can comment early and prevent rework. Mark the merge requestWork In Progressso it is not merged by accident.
16.When you create a merge request,mentionthe issue(s) that it solves in the description. If any followup actions are required on the issue after the merge request is merged, like reporting back to any customers or writing documentation, avoid auto closing it by sayingFixes #1orCloses #1.
17.Once a merge request is created, make sure to assign it to the proper person:
1.For example a merge request that fixes a frontend issue should have theFrontendlabel and be assigned to a Frontend Engineer for review. For other workflow labels please seePROCESS.md.
2.A merge request that is related to Continuous Integration should be assigned to the GitLab CI lead.
3.All other merge requests should be assigned for review to either a merge request miniboss or endboss. You can find the people with these roles on theteam page.
4.Once a merge request has gone through review by a miniboss, they will assign it to an endboss who will do a final review and perform the actual merge if satisfied.
18.Whenyouare done with your merge request, remove the WIP prefix andassignthe merge request to someone to review and merge it. You can still make changes based on feedback of course, but by removing the WIP prefix it clarifies when the main body of work is completed.
19.When a merge request is done, set milestone to the version it should be included in.
20.If you are assigned to review and merge a merge request and would like the creator to make somechanges, comment on the merge request and assign it back to the creator. When they have addressed the concern, they will reassign it to the reviewer.
21.If you are assigned to merge a merge request and there is amerge conflict, consider trying to resolve ityourselfinstead of asking the MR creator to resolve the conflict. If it is easy to resolve you avoid a round trip between you and the creator, and the MR gets merged sooner. This is a suggestion, not an obligation.
22.If you ask a question to a specific person, always start the comment by mentioning them; this will ensure they see it if their notification level is mentioned and other people will understand they don't have to respond.
23.Do not close an issue until it is fully done, which means code has been merged, it has beenreportedback to any customers and the community, all issue trackers are updated and any documentation is written and merged.
24.Whenclosingan issue leave a comment explaining why you are closing the issue.
25.If a user suggests an enhancement, try and find an existing issue that addresses their concern, or create a new one. Ask if they'd like to elaborate on their idea in one of these issues.
Select Language