Talk:Process
I think 'User' should be described as both 'finding issues' and 'suggesting improvements' for Moodle, even if the detail of how things are implemented are left for the Product Owner. Just thinking that a good chunk of the things I add to the Tracker are suggestions for improvement rather than 'issues' as such and that we should promote this idea as a general rule - maybe :)
- I agree with Mark. Bug tracker should be used for actual bugs. Discussion about future roadmaps, enhcnements and improvements is a separate matter, and in actual fact it is hard to engage in this. I don't have an answer at the moment. Maybe a place to discuss, and notification of when discussions have heated up (like specs are being prepared and a new roadmap developed for a component) ie owners manage the discussion, but there is a clear place to go to engage, some indication of timelines etc. --Derek Chirnside 19:39, 25 November 2010 (UTC)
Well, "issues" there was meant to cover "bugs" and "suggestions", as the tracker does both. I'll make it more explicit though. Martin Dougiamas 10:12, 30 November 2010 (UTC)
OK - I could live with this. But I still prefer this clearer distinction as suggested by Mark:
User role
- Uses Moodle
- Finds issues/bugs (report in tracker)
- Suggests improvements (report in tracker)
Question: is there a way in the tracker to keep issues in two lists: bugs and suggestions? Maybe even like Google: you can suggest anything, but at any given time there are a few suggestions up for vote? In Moodle, you can discuss anything, but someone is highlighting at any given time a few topics for focused discussions. On reflection the answer may be No - on this basis I am back to my original suggestion.
A bug is a bug - it is not working as we know it should. A suggestion for an enhancement is partly an invitation to dialogue, vote. Voting for bugs is silly - all bugs need fixing, and priorities are best (IMO) determined centrally. So:
- Uses Moodle
- Finds and reports bugs (use tracker)
- Suggests improvements (use tracker)
- Takes part in dialogue around suggested improvements
Derek Chirnside 06:18, 4 December 2010 (UTC)
- Derek, thanks for your comments. Regarding a way in the tracker to keep issues in two lists: bugs and suggestions, when you create an issue you have a choice of issue types - bug, new feature, task and improvement. Thus, a search for all new features and improvements should generate a list of suggestions. --Helen Foster 14:31, 4 December 2010 (UTC)
Backlog naming
Regarding the latest change about naming backlog versions with "STABLEBACKLOG/DEVBACKLOG", I'd recommend to use instead something like: "1.9.x backlog/2.0.x backlog/2.1.x backlog" because:
- It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
- It supports multiple stable branches, like we have now (1.9.x, 2.0.x...)
- It respects the format used by both the Affected Branches and Fixed Branches custom fields that are really useful for a lot of filters.
Ciao, Eloy Lafuente (stronk7) 23:33, 6 December 2010 (UTC) :-)
- Addenda: Finally it has been decided to go to 2 backlogs only (stable/dev). Fair enough so developer (team) will look to the real branches were solution needs to be implemented. Eloy Lafuente (stronk7) 10:23, 9 December 2010 (UTC)
This does not look like scrum to me at all
I think we need a certified scrum master. This proposal IMHO seems to break nearly all the good Scrum practises described in books.
Ciao, Petr Škoda (škoďák) 10:03, 9 December 2010 (UTC)
- Agree! some points (see point 3 especially, both in STABLE/DEV teams, break the thing. It's (scrum, by team) master responsibility to discuss with product owner, not team itself! Isolation is a MUST.
- Ciao, Eloy Lafuente (stronk7) 10:12, 9 December 2010 (UTC)
If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG
Hmm, maybe this should be governed up by bug severity too? You, sure, aren't going to say that every bug requiring DB update, however severe it is, should be left up to the next major release? --Oleg Sychev 14:51, 9 December 2010 (UTC)
I understand the idea of pulling from the items with the highest priority; however, how are we going to determine that priority. We have issue severity which has traditionally been seen as a priority indicator but we also have the number of votes. I am curious when paper cuts will be taken care of. These smaller issues can impact the user experience. I suspect in an ideal world, all the major issues will be dealt with but occasionally some simple fixes come along with patches in the tracker and it would be good to get those applied. Peace - Anthony
- Well, in practice I expect people will choose items based on a cost/benefit analysis of fixing them - just like they always have in the past.--Tim Hunt 18:14, 16 December 2010 (UTC)
Suggested changes for "External Developers"
I had a really good conversation with David (He posted a screenshot that maybe does a better job of explaining what is described below: http://picasaweb.google.com/david.mudrak/Moodle#5551427587739059122), and we discussed one possible suggested workflow external developers can use if they choose to use their own GIT repo. Here's how it would break down:
Creating repo
Branch off MOODLE_20_STABLE (ie: UCLA_TRUNK)
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE $ git checkout -b UCLA_TRUNK origin/MOODLE_20_STABLE
commit customizations into branch
$ ... (hack something, git add, git commit) $ git push
Contributing back
Create another branch off MOODLE_20_STABLE (ie: COOL_NEW_FEATURE)
$ git --bare fetch git://git.moodle.org/moodle.git MOODLE_20_STABLE:MOODLE_20_STABLE $ git checkout -b COOL_NEW_FEATURE origin/MOODLE_20_STABLE
git cherry-pick to selectively pick commits from UCLA_TRUNK to merge into COOL_NEW_FEATURE
$ git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544
publish branch COOL_NEW_FEATURE
??
create pull request in tracker
http://tracker.moodle.org/browse/PULL-18
If accepted, it becomes part of core moodle
Updating to next version of Moodle
$ git pull
Contrib Code - Development process
I think this may be a good time to give some thought to coming up with the process we want to implement and enforce for sharing CONTRIB code. What assumptions do we want to make from the beginning? Should shared code be in a git repository somewhere? We have folks that share everything from zip files of plugins, some use Google code, others may use git. My experience has been that many are not initially proficient at using CVS/GIT, etc. although this seems to be improving. In any case, I would love to see a clear diagram about what someone does when they create code that they want to share. It has worked well to initiate conversations in the tracker as I can them work them through the Guidelines for CONTRIB Code (https://docs.moodle.org/en/Development:Guidelines_for_contributed_code) but I think we need to update that now for how we want to handle things in the future. Perhaps the improved M&P database will be the point of first contact. In any case, I would love to see if we could create a page similar to the Development:Process called something like Development:CONTRIB process. Peace - Anthony
External developers
I have a question about the historical integrity of providing patches via links. For external developers, we say "Suggest code via links in comments in Jira". What happens if those links no longer work? Perhaps this is a trivial issue and will in practice hardly ever happen but I was thinking about going back to an older issue that it may be helpful to see an approach that was attempted but rejected. If the external developer removes the branch, then it would seem to me that perhaps their rejected patch would no longer be available to be reviewed later. Am I understanding this properly and if so, might we consider what the approach might be for getting patches in the tracker so that they can stay there? Peace - Anthony
About the "Commit messages" section in the page
IMO that information is:
- Absolutely inaccurate. A lot of people has never used that commit messages structure at all.
- Completely out of context: Unrelated with the purpose of the page (the development process, not its specifications or guidelines).
So my +1 to take it out from there ASAP. Ciao :-) --Eloy Lafuente (stronk7) 00:23, 4 March 2011 (UTC)
- Eloy, you are a senior developer. Please update the information and move it somewhere else. (Assuming other people agree.)
- The information about commit messages needs to be seen by all Moodle developers (HQ and elsewhere) because they need to write good commit messages, module owners and integration reviewers, who need to review what developers have done. It is part of "How to do Moodle development", which is sort of what this page is about. (I copied this information from CVS for developers which is an even worse place for it to be these days. Perhaps we should create a new page Commit messages (perhaps) and link to it from the git docs and the coding guidelines. (And probably a see-also link from here.)--Tim Hunt 08:17, 4 March 2011 (UTC)
- +1 for a new page e.g. Commit messages as Process is a long page and shorter pages are much easier to read. --Helen Foster 09:33, 4 March 2011 (UTC)
- +1 for a new page as proposed above. Now we only need to agree about the format of the commit messages (or allow both alternatives that IMO will be the only way to go ahead in the agreement). --Eloy Lafuente (stronk7) 10:57, 4 March 2011 (UTC)
- Try git log --no-merges --oneline It looks to me like bug number first is winning, and also, it is easier to skim-read the output in the sections where all the commits have the bug number first. For example this block is easy to skim read:
71550f6 MDL-26212 - fix scorm player size on resize of browser window - bump sco a537e50 MDL-24898 external blogs - strip html and truncate subject 28765cf MDL-25575 fix broken block support in get_courseid_from_context() 9c14c1c MDL-26223 prevent getting content of hidden blocks in edit mode 3b07325 MDL-26314 fix phpdocs typo 44303ca MDL-25974 fix access to activities when role switched in hidden course a d07f2de MDL-25998 fix default manual enrol role ad9ab4d MDL-26131 fix several collapsible_region issues 743fff9 MDL-26142 fix immediately spelling in strings, comments and code ae3a794 MDL-26355 increase size of installer forms fields b3929ae MDL-26383 add missing bloglevelupgrade admin section 4f97de7 MDL-23939 do not load groups and profile for guest user because they can cc10c0b MDL-23939 minor course_display coding style improvements and inline docs 13801a4 MDL-23939 lazy load course_display with new course_get_display() 6e6034e MDL-26153 fix yui combo loading for images with numbers in file name dd3b7e7 MDL-26294 fix byteserving regression 3612c3b MDL-25612 sql - make rss_client block cross-db 9e9543e MDL-26307 fix dbport and dbsocket support when creating mysql database a2ee26b MDL-26030 more mediaplugin fixes b69f9a0 MDL-25626 fix incorrect cm id in completion report e07c51c MDL-26371 sql - avoid distinct + text in lesson essay & report b37d06c MDL-26371 sql - avoid distinct + text in glossary search cd138b2 MDL-26376 fix incorrect Shibboleth string and undefined property during
- This bit is much harder, until you get to all the gradebook ones which make things line up again:
90c2f51 qtype_multianswer MDL-25841 feedback pop-up was appearing in the wrong p 151c228 quiz MDL-25884 mod/quiz/index.php broken when logged in as a student. 2c00fa1 qformat_gift MDL-26059 fails to import truefalse questions with answer t 89b4ffe completion MDL-25929 Added upgrade change to remove unused setting 27d6ab5 lib MDL-26044 Optimise moodle_url based on profiler data a1e26b5 gradebook MDL-20617 Fixed SQL formatting a071dbb gradebook MDL-20617 added more control over what columns are displayed o 25081b9 gradebook MDL-25769 Fixed SQL syntax formatting f2491a1 gradebook MDL-25769 switched a query over to use named params 2dc5e58 gradebook MDL-25769 fixed some problems identified by peer review 387815d gradebook MDL-25769 fixed up the grader report b61e4f4 gradebook MDL-25769 fixed grade/import/lib.php get_unenrolled_users_in_i ef8f084 gradebook MDL-25769 fixed the loading of users in the grader report e8aad16 gradebook MDL-25887 Fixed whitespace
- So, we just weed to win over the Perth devs.--Tim Hunt 14:38, 4 March 2011 (UTC)
