Scholarpedia:Development

Page detailing development practices and routines.

Schedule

(Commits to codebase can happen any time) Note: May want to move production deployment to Tuesday

Saturday, 11:59pm Pacific Time

• Code for Tuesday deployment is frozen
• All code for Tuesday production deployment must be in "Deployed" status (see below)
• Any SVN changes will not be permitted for Tuesday deployment

Sunday - Tuesday

• Code and functionality review by all parties

Monday meeting

• Verify that which changes will go live in production server.
• Code must be reviewed and in "Accepted" status by beginning of Monday meeting
• Tuesday: code deployment
• Review and prioritize upcoming feature additions, changes, etc.

Pivotal tracker

Prioritization

L and E need to comment on all pending tasks, indicating whether they should be implemented soon and why. Also, order the tasks.

All un-commented tasks will be deemed to have been non-reviewed.

Task ordering needs to be seen as important.

Developers need to review estimated task difficulty.

"Finished" status

• Functionality has been written
• Test has been created to determine if it works and to detect regressions

"Deployed" status

• Functionality has been deployed to test server and visually tested by the developer

"Accepted" status

• Code has been reviewed by someone other than original developer
• Test has been reviewed by someone other than the original developer
• Functionality has been visually evaluated on test server

Code practices

• Use hooks whenever possible
• All changes to stock MediaWiki should follow CP-prefix conventions (ideally, code should be migrated out of stock mediawiki)

Checking-in Third-Party Code (such as MediaWiki extensions)

Please follow the conventions described here for checking-in third-party code, such as MediaWiki extensions. To summarize, third-party code should be checked-in to the vendor branch, not the cpweb branch.