Conversation
| continue to the next step. | ||
|
|
||
| 1. Assign the issue to yourself, and change the milestone from Backlog to the currently active | ||
| milestone. |
There was a problem hiding this comment.
It would help to decide how we plan on organizing work. Milestones? Projects? Both?
I prefer we stick to just projects right now. They can do what milestones do (show progress) and give us a trello like view. I think our goals are small enough that we don't need to have to use both. The contributing docs should point this out.
If we have a really huge project, then we can break it down into milestones. Though I'm not quite sure how elegant that is with GH.
There was a problem hiding this comment.
@mostlygeek I've been using Projects to track large bodies of work and Milestones to track releases. That's worked well for me so far. Using milestones to track releases makes it easy to reflect to QA which issues were closed in a given release, and to historically reconstruct when things were deployed.
peterbe
left a comment
peterbe
left a comment
There was a problem hiding this comment.
Mostly comments.
I insist that @mythmon 's comment about having to squash is wrong. If we're not going to bors it, at least the person responsible for the approval of the PR should use "Squash and merge" if we want a clean commit log.
|
"As of January 1 2019, Mozilla requires that all Github projects include this So basically, I think we should exclusively use that to refer to any code of conduct in this project's |
Capitalize Issue Co-Authored-By: jaredkerim <[email protected]>
| information you'd like to the pull request body, including descriptions of changes, screenshots | ||
| of any UI changes, special instructions for testing, etc. | ||
|
|
||
| 1. Find a reviewer. If you're not sure who should review, please contact us on #experimenter on |
There was a problem hiding this comment.
I'm not sure you can assign a reviewer if you don't have elevated permission to the repo. Right? So if you're a contributor all you can do is create the PR and if, by some luck, you know who should look at it you can get their attention with a @ mention in the description.
So, we could say "Request a reviewer if you have access to do so. If not, leave the reviewer unset and the core team will triage it and assign a reviewer."
Also, an interesting topic is for the core team; if you have a PR but don't really care about who does it as long as it's anybody-but-self. What do you do? Leave it unset? Or request a review from all other core team members hoping that the first one to react starts reviewing.
Actually, I think, if I request a review from you, and him, and her, I expect that they all review. And that's a big ask.
There was a problem hiding this comment.
@peterbe Yeah I see what you mean, but I think if someone doesn't have permissions for the repo then just going to IRC and asking is their only recourse and it's stated clearly. As far as the more nuanced matter of who on the team should review each others code, always assign to me and if I can't do it I will throw it to @mythmon and run away before he can refuse.
There was a problem hiding this comment.
Github also has a feature where you can request/require review from a certain team or set of users, without individually requesting it. That might be a more scalable solution we can explore in the future.
peterbe
left a comment
peterbe
left a comment
There was a problem hiding this comment.
I believe all the bits I a first reacted to is resolved. Feel free to make your own call on the nitpickery I brought up regarding finding a reviewer.
|
@mythmon @mostlygeek Do you have any other feedback? |
|
It looks OK. Merge when ready. |
4 participants
No description provided.