Development:Process: Difference between revisions
Line 22: | Line 22: | ||
===Product owner role=== | ===Product owner role=== | ||
# Maintains overall roadmap based on issues | # Manages community discussions/feedback | ||
# Maintains overall roadmap and goals based on issues + community | |||
# Develops detailed specifications | # Develops detailed specifications | ||
# Maintains backlog of issues, updates priorities | # Maintains backlog of issues, updates priorities to produce a queue | ||
===Internal HQ Development team=== | ===Internal HQ Development team=== |
Revision as of 10:15, 30 November 2010
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
- Uses Moodle
- Finds issues (both "bugs" and "suggestions")
- Report issues to tracker
Triage role
- Reads new issues in Jira
- Housekeeping, cleaning up duplicates etc
- Updates priorities/assignees/descriptions/status
Product owner role
- Manages community discussions/feedback
- Maintains overall roadmap and goals based on issues + community
- Develops detailed specifications
- Maintains backlog of issues, updates priorities to produce a queue
Internal HQ Development team
- Selects work from the backlog for one development period
- Assigns work to team members
- Develops solutions on local git installs
- Pushes solutions as issue-named branches to public repositories (moodle.com ?)
- Suggest code via links in comments in Jira
- Conduct basic peer-reviews of code between team members (direct communication and Crucible)
External developers
- Develop whatever they like, however they like!
- Publish to public git repositories (github, gitorious, whatever)
- Create/find issues in Jira
- Suggest code via links in comments in Jira
Component maintainer role
- Selects final solution for each issue
- 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.
- 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)
- Each new “pull request” is either accepted or rejected with comments.
- 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”
- 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
- Go through the “QA review” issues in the “pull request” queue.
- Test the new features/fixes on automatically-built Moodle sites (or their own)
- Sign off on the fix and change the status of the “pull request” to “QA success”.
- 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.
- 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”.
- Push the integrated Moodle branches to the production server.
- Close the original Jira issues, say thanks and buy drinks.
Overview of the process
Diagram coming soon