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 versions (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 STABLE backlog
   2. If the issue is related to backup and restore, assign "Fix version" to STABLE backlog with high priority
   3. If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEV backlog
   4. If the issue is a feature request, assign "Fix version" to DEV backlog

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.

Commit messages

Every commit should have a commit message to help other developers follow and review what is being changed. They are very helpful when tyring to understand a piece of code. The command git blame will tell you who last changed each line of code, and when they did it. Then you can look at the commit comments to tell you why that change was made.

A commit message should contain, in order:

• A couple of words indicating which part of moodle this change affects. For example 'forum backup', 'quiz attempting' or 'weblib'.
• A tracker issue id like MDL-12345. (If necessary, create an issue before committing, the only exception is for very minor typos.)
• A brief description of the problem you are fixing. (If you are feeling lazy, you may be able to get away with copying and pasting the issue summary from the tracker.)
• If it is not immediately obvious, a brief summary of why this change fixes the problem. If a longer description is necessary, you may also want to add more information to the tracker issue, or Moodle Docs, but the code changes + commit message should provide enough clues to how the fix works on their own.

Here is an example of a commit message from a simple change:

user selection: MDL-17072 Polishing the role assign page. Do processing before print_header in line with best practice.

Actually, the ideal commit message would be a bit shorter than that. It is good if the first three items (area of Moodle, tracker id and brief description) will fit in the subject line of an email message, so the first line should be shorter than about 70 characters if possible.

Here is an example from a bigger commit (would it have been better if this could have been done as several smaller commits?):

role overrides: MDL-17070 Improve override roles page to match the recent usability improvements on the assign page.

Including:
MDL-11529 When assigning/overriding roles, the dropdown for switching to
another role should have a number in brackets

MDL-16549 Should not be able to edit the permission associated with
moodle/site:doanything on any role.

Here is an example of a commit (from a while ago, which is why the issue number is in the wrong place) with some explanation of the change:

accesslib: get_user_by_capability() - Handle complex rolecap resolution

With this patch, get_user_by_capability() can handle the cases where
users have multiple role assignments to the same course, and PREVENTs
and PROHIBITs affect the rolecaps of this course.

Without stored procedures we cannot resolve this entirely on the
server side - so in the complex cases we do as much as we can on SQL,
and post-process the data on the PHP side, including SQL-style
pagination.

MDL-12452

Workflow in tracker

Proposed new workflow for MDL issues.

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, commit to integration repo
• Tuesday - QA testing on all code accepted on integration repository
• Wednesday - code pushed to main 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

Here are the tasks for a typical scrum, in progress, as represented in the tracker: