Process

We are planning a new development process for future work on Moodle to integrate reviews at many levels throughout the process of code development.

Roles

Let's look at the roles through the new system. Note that one person may perform more than one of these roles, depending on their job description. However, no-one should ever be reviewing their own code.

User role

1. Find issues with Moodle
2. Report issues to tracker

Triage role

1. Reads new issues in Jira
2. Housekeeping, cleaning up duplicates etc
3. Updates priorities/assignees/descriptions/status

Product owner role

1. Maintains overall roadmap based on issues/community/goals etc
2. Develops detailed specifications
3. Maintains backlog of issues, updates priorities etc

(What about "manages discussion, dialogue around the future with users" was unsure where to put feedback on this, thought people may not have seen the discussion, feel free to delete.)

Internal HQ Development team

1. Selects work from the backlog for one development period
2. Assigns work to team members
3. Develops solutions on local git installs
4. Pushes solutions as issue-named branches to public repositories (moodle.com ?)
5. Suggest code via links in comments in Jira
6. Conduct basic peer-reviews of code between team members (direct communication and Crucible)

External developers

1. Develop whatever they like, however they like!
2. Publish to public git repositories (github, gitorious, whatever)
3. Create/find issues in Jira
4. Suggest code via links in comments in Jira

Component maintainer role

1. Selects final solution for each issue
2. Submits “pull request” to a queue for Integration Review

Integration reviewer role

Only these people have write access to the integration repository git.moodle.org/integration.git.

1. At set times per week, the Integration Review team goes through the current queue of “pull requests” (reviewers must not review/commit their own code)
2. Each new “pull request” is either accepted or rejected with comments.
3. If accepted then the “pull request” is merged into the integration repository to Moodle branches and the “pull request” issue changes status to “QA review”
4. If rejected then the reviewer marks the pull request as “Rejected” and the component maintainer is told why in the Jira issue

QA testing role

1. Go through the “QA review” issues in the “pull request” queue.
2. Test the new features/fixes on automatically-built Moodle sites (or their own)
3. Sign off on the fix and change the status of the “pull request” to “QA success”.
4. If the test fails, comment and change the status of the “pull request” to “QA fail”

Production maintainer role

Only these people have write access to the official production repository git.moodle.org/moodle.git, and all commits come direct from the integration repository.

1. At set times per week, go through the list of “QA fail” and “QA review” pull requests and make sure that code is not in the integration server, or that the Integration reviewer fixes them. All pull requests should be closed with “QA success” or “Rejected”.
2. Push the integrated Moodle branches to the production server.
3. Close the original Jira issues, say thanks and buy drinks.

Overview of the process

Diagram coming soon