Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Process: Difference between revisions

From MoodleDocs
Line 36: Line 36:
Ciao, [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 23:33, 6 December 2010 (UTC) :-)
Ciao, [[User:Eloy Lafuente (stronk7)|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. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 10:23, 9 December 2010 (UTC)


==This does not look like scrum to me at all==
==This does not look like scrum to me at all==

Revision as of 10:23, 9 December 2010

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

  1. Uses Moodle
  2. Finds issues/bugs (report in tracker)
  3. 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:

  1. Uses Moodle
  2. Finds and reports bugs (use tracker)
  3. Suggests improvements (use tracker)
  4. 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:

  1. It saves us to move things when a new major release happens (so it won't be necessary to move all the DEVBACKLOG => STABLEBACKLOG".
  2. It supports multiple stable branches, like we have now (1.9.x, 2.0.x...)
  3. 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)