Process

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

Terms

Here are some terms we'll use in this document:

• STABLE = the next stable minor version of Moodle (eg 2.0.1, 2.0.2 ... etc) Note that database changes and new features are not allowed in STABLE
• STABLE backlog = the queue of bugs to be fixed in STABLE (eg 2.0.x)
• DEV = the next major version of Moodle (eg 2.1, 2.2, 2.3 ... etc)
• DEV backlog = everything to be looked at for upcoming major version (eg 2.X)

Roles

Let's look at the roles in 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. Uses Moodle
2. Finds issues (both "bugs" and "suggestions")
3. Report issues to tracker

Triage role

Initial staff: Eloy, Helen

1. Reads new issues coming into Moodle Tracker
2. Performs housekeeping, fixes spelling, removes duplicates and spam, updates priorities/assignees/components/descriptions/statuses.
3. For items in core:
   1. If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" as STABLEBACKLOG
   2. If the issue is related to backup and restore, assign "Fix version" to STABLEBACKLOG with high priority
   3. If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG
   4. If the issue is a feature request, assign "Fix version" to DEVBACKLOG

Product Owner role

Initial staff: Martin

1. Monitors DEVBACKLOG, updates priorities to produce a queue
2. Manages community discussions/feedback
3. Maintains overall roadmap and goals based on issues + community
4. Develops detailed specifications

Scrum Master role

Initial staff: ???

1. Coaches and helps the team to finish each sprints
2. Holds sprint restrospective meetings
3. Keeps documentation updated

Moodle HQ Stable Maintenance team

This SCRUM team generally works on the bugs important for improving the current stable release (STABLEBACKLOG). Just before any major release they also work on backup/restore for that release. This ensures a good familiarity with the code-base of the next release.

Initial staff: Andrew, Aparup, Dongsheng, Jerome, Rossi, Sam

1. Selects one month's work (STABLEBACKLOGSPRINT) from the highest priority in STABLEBACKLOG
2. Assigns X to them so they are visible/manipulable in Greenhopper as a Sprint, eg "Jan 2011", and also get assigned "Fix version" of the next minor release (eg 2.0.1).
3. Meets with Product Owner to resolve any questions, agree on details
4. Assigns work among team members
5. Meets daily with Scrum Master to keep on track, resolve issues
6. Develops solutions on local git installs
7. Pushes solutions as issue-named branches (eg wip-MDL-12345) to a public repository (moodle.com ?)
8. Publish suggested code via links in comments in Jira
9. Conduct basic peer-reviews of code from other team members (direct communication, Jira, Crucible?)
10. Rebase WIP branches and remove "wip-" from the name so it's called MDL-12345
11. Create PULL requests for each issue or group of related issues for Integration review

Moodle HQ New Developments team

Initial staff: David,

1. Selects one month's work (DEVBACKLOGSPRINT) from the highest priority in DEVBACKLOG
2. Assigns X to them so they are visible/manipulable in Greenhopper as a Sprint, eg "Jan 2011", and also get assigned "Fix version" of the next major release (eg 2.1).
3. Meets with Product Owner to resolve any questions, agree on details
4. Extend/deepen specifications as necessary
5. Assigns work among team members
6. Develops solutions on local git installs
7. Pushes work-in-progress solutions as issue-named branches (eg wip-MDL-12345) to a public repository (moodle.com, github.com ?)
8. Publish suggested code via links in comments in Jira
9. Conduct basic peer-reviews of code from other team members (direct communication, Jira, Crucible?)
10. Rebase WIP branches and remove "wip-" from the name so it's called MDL-12345
11. Create PULL requests for each issue or group of related issues for Integration review

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. Reviews and selects final solution for each issue in their control
2. Possibly rebases, cleans up
3. Create PULL requests for each issue or group of related issues for Integration review

Integration reviewer role

Initial staff: Petr, Eloy, Sam

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

Initial staff: Helen, volunteers

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

Initial staff: Petr, Eloy

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.

Scheduling

Here are some suggested scheduling times for different parts of the process.

Integration review

• Monday - Review team divides PULL backlog and reviews all code -> Accept/Reject
• Tuesday - Review and code re-submitted after rejection -> Accept/Reject
• Tuesday, Wednesday, Thursday - QA testing on all code accepted on integration repository
• Friday - Production maintainers update pull requests and Jira issues, and push code to production repository

Stable scrum sprints

• Day 1, Sprint planning meeting, choosing and assigning high-priority tasks from the backlog to the sprint
• Day 2-19, daily stand-up meeting, developing solutions, add requests to the PULL backlog
• Day 20, Sprint Review meeting, Sprint Retrospective meeting