Process - Revision history

Stronk7: Part of MDLSITE-7135 - document the removal

2023-03-24T11:02:54Z

Part of MDLSITE-7135 - document the removal

← Older revision		Revision as of 11:02, 24 March 2023
Line 169:		Line 169:
	After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.		After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.

	If you've set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration], the issue will automatically show the ~~Travis~~ build status for the branch(es) you've submitted for peer review.		If you've set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration], the issue will automatically show the GitHub Actions build status for the branch(es) you've submitted for peer review.

	===Peer review===		===Peer review===

Stronk7: Part of MDLSITE-7135 - document the removal

2023-03-24T10:58:19Z

Part of MDLSITE-7135 - document the removal

← Older revision		Revision as of 10:58, 24 March 2023
Line 169:		Line 169:
	After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.		After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.

	If you've set up [~~[Travis~~ integration]], the issue will automatically show the Travis build status for the branch(es) you've submitted for peer review.		If you've set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration], the issue will automatically show the Travis build status for the branch(es) you've submitted for peer review.

	===Peer review===		===Peer review===
	The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.		The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Stronk7: Part of MDLSITE-7135 - document the removal

2023-03-24T10:57:16Z

Part of MDLSITE-7135 - document the removal

← Older revision		Revision as of 10:57, 24 March 2023
Line 154:		Line 154:
	You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like MDL-12345-31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.		You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like MDL-12345-31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

	Consider setting up [~~[Travis~~ integration]] with your repository so tests will be automatically run for you whenever you push work on your fix.		Consider setting up [https://moodledev.io/general/development/tools/gha GitHub Actions integration] with your repository so tests will be automatically run for you whenever you push work on your fix.

	===Submit your code for peer review===		===Submit your code for peer review===
	Once your fix is done, it should be submitted for a peer review.		Once your fix is done, it should be submitted for a peer review.

Devdocsbot: Protected "Process": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

2022-05-06T07:27:22Z

Protected "Process": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

← Older revision		Revision as of 07:27, 6 May 2022
(No difference)

Andrewnicols at 03:48, 11 April 2022

2022-04-11T03:48:39Z

← Older revision		Revision as of 03:48, 11 April 2022
Line 1:		Line 1:
			{{Template:Migrated\|newDocId=/general/development/process}}
	This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.		This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.
	==Integration workflow in the tracker==		==Integration workflow in the tracker==

Andrewnicols: Add details of component lead review

2022-01-24T07:22:47Z

Add details of component lead review

← Older revision		Revision as of 07:22, 24 January 2022
Line 18:		Line 18:
	===Component leads===		===Component leads===
	[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components. Note that, apart from that, every component also has some [[Component Leads\|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.		[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components. Note that, apart from that, every component also has some [[Component Leads\|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.

			===Component leads reviewers===
			Component Lead Reviewers are Component Leads who have the added responsibility of performing a second and final review of a selection of issues within their component.
			After reviewing the code, it is sent to the integration team to be pulled without further review.

	===Integrators===		===Integrators===
	On Monday ~~and Tuesday of each week~~, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.		From Monday to Thursday, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

	If they find problems they reject the issue and send it back to the developer for further work.		If they find problems they reject the issue and send it back to the developer for further work.

	===Testers===		===Testers===
	~~On Wednesday~~ each week, testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions in the web version and the Moodle mobile app.		During each week the testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions in the web version and the Moodle mobile app.

	If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.		If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

	See [[Testing of integrated issues]] for more details.		See [[Testing of integrated issues]] for more details.

	===Production maintainers===		===Production maintainers===
	On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.		On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.
Line 34:		Line 41:

	At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles\|major releases]]).		At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles\|major releases]]).

	===Minor release (point release) timing===		===Minor release (point release) timing===
	After [[#Major_release_cycles\|major releases]] there will be minor releases.		After [[#Major_release_cycles\|major releases]] there will be minor releases.
Line 39:		Line 47:
	* There will then be another point release every two months after that.		* There will then be another point release every two months after that.
	See the [[Releases#General_release_calendar\|General release calendar]] for details.		See the [[Releases#General_release_calendar\|General release calendar]] for details.

	===Issue triage===		===Issue triage===
	[[Bug_triage\|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.		[[Bug_triage\|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

	At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).		At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

	===Scrum===		===Scrum===
	At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.		At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.
Line 51:		Line 61:

	Whenever a solution for an issue is finished, it is submitted to the standard integration workflow process described above.		Whenever a solution for an issue is finished, it is submitted to the standard integration workflow process described above.

	==Major release cycles==		==Major release cycles==
	Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar\|General release calendar]] for more details.		Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar\|General release calendar]] for more details.
Line 123:		Line 134:

	Process and the list of things to check are described in [[Peer reviewing]].		Process and the list of things to check are described in [[Peer reviewing]].

	===Submit the code for integration===		===Submit the code for integration===
	The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.		The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

	Submitting an issue to integration is much the same as for any Moodle code. See [[Integration Review]] and the information about the integration workflow above.		Submitting an issue to integration is much the same as for any Moodle code. In some cases the Component Lead may perform a Component Lead Review instead of the integration team. See [[Integration Review]] and the information about the integration workflow above.

	==Fixing a bug==		==Fixing a bug==
	Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)		Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

Sander@moodle.com: /* Define roadmap */

2021-09-30T00:48:39Z

Define roadmap

Show changes

Mudrd8mz: Reverted edits by Mudrd8mz (talk) to last revision by Finns

2021-08-09T13:17:26Z

Reverted edits by Mudrd8mz (talk) to last revision by Luca Bösch

← Older revision		Revision as of 13:17, 9 August 2021
Line 178:		Line 178:
	Submitting an issue to integration is much the same as for any Moodle code. See [[Integration Review]] and the information about the integration workflow above.		Submitting an issue to integration is much the same as for any Moodle code. See [[Integration Review]] and the information about the integration workflow above.

	==~~tableing~~ a bug==		==Fixing a bug==

	Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)		Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

Mudrd8mz: MDLSITE-6551

2021-08-09T13:06:59Z

MDLSITE-6551

← Older revision		Revision as of 13:06, 9 August 2021
Line 178:		Line 178:
	Submitting an issue to integration is much the same as for any Moodle code. See [[Integration Review]] and the information about the integration workflow above.		Submitting an issue to integration is much the same as for any Moodle code. See [[Integration Review]] and the information about the integration workflow above.

	==~~Fixing~~ a bug==		==tableing a bug==

	Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)		Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)

Finns at 21:46, 5 April 2021

2021-04-05T21:46:47Z

← Older revision		Revision as of 21:46, 5 April 2021
Line 274:		Line 274:
	Walks-though of the process for contributors:		Walks-though of the process for contributors:
	* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM		* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
	* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU		* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU and https://youtu.be/Hu8ne0NCRAg?t=11659

	[[Category:Processes]]		[[Category:Processes]]