Skip to content

Instantly share code, notes, and snippets.

@weaverryan

weaverryan/README.md

Last active August 29, 2015 14:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save weaverryan/dc827e5368ddc9e5bb79 to your computer and use it in GitHub Desktop.
Save weaverryan/dc827e5368ddc9e5bb79 to your computer and use it in GitHub Desktop.
Download ZIP
webmozart workflow
Raw
README.md
  1. A team (I'll call it the "Label Team" here) is responsible for marking new issues/PRs with:
  • the label for the component, like "Serializer"
  • the labels "Bug" for bug reports
  • the label "Feature" for feature requests
  • the label "Enhancement" for smaller enhancements of existing features (idea: less work than "Feature" tickets)

At the beginning, the Label Team is the core team, but is slowly replaced by other community members (see below).

  1. A bot automatically marks new PRs and new tickets with the "Bug" label with the label "Needs Review"

  2. Community members (I'll call them a "Community Reviewer" or CR) pick issues/PRs using the GitHub query "label:Needs Review" (we could post a permalink to that query somewhere).

  3. The CR does a review by following a checklist similar to the link above.

  4. If the issue satisfies the checklist, the CR applies the label "Reviewed" (via a bot [1]).

  5. If the issue does not satisfy the checklist, the CR applies the label "Needs Work" (for PRs or bug reports with missing reproduction steps) or "Works for me" (for bug reports that are not reproducible)

  6. The core team picks issues/PRs with the GitHub query "label:Reviewed" and gets a filtered list of reviewed bug reports and PRs that can hopefully be dealt with quicker/more easily.

Possible ticket states:

Bug Reports: New -> Needs Review <-> Reviewed|Needs Work|Works for me

PRs: New -> Needs Review <-> Reviewed|Needs Work

Community Reviewers receive points for every successful review [2]. We could have badges for different steps (1 review, 10 reviews, 25 reviews, 100 reviews etc.) as motivation. Additionally, we should list the top 3 or 5 reviewers of the week in every "A week of Symfony" post to publicly recognize these people and spur some competition.

Community Reviewers with a certain number points could further become members of the Label Team (who need repo write access) so that more people do the labeling.

I think with this process we could motivate more people to contribute with a lower barrier to entry. Community Reviewers further become familiar with the Symfony code and are potential future core developers.

Two questions remain:

[1] How to implement state changes of tickets?

I think we could do this with a bot. If the last line of a comment is "Needs Review", "Reviewed", "Needs Work" or "Works for me", the bot changes the labels of the ticket to do the state change.

[2] How to distribute points to the Reviewers?

With the bot, we already know if a person did a review (the last line of their comment is "Reviewed", "Needs Work" or "Works for me") and we can give that person a point. However, unless we check the quality of a review, people could collect points for badly done reviews. I think we should be optimistic and hand out points by default. If we see that people start doing bad reviews just to get points, we can warn them. If they still continue, we can disable review points altogether for that person.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment