Changes to assignment of Tracker issues in the Moodle project

Changes to assignment of Tracker issues in the Moodle project

by Michael de Raadt -
Number of replies: 8

Hi, all.

You may soon see developers unassigning themselves from issues that they do not intend to work on in the immediate future. This is intended to create a truer sense of the state of issues for the following reasons.

Previously, the Moodle Tracker system required each component to have an automatic assignee. This meant that each reported issue was assigned to a real developer (or to an artificial user). While this did allow issues to have someone's eyes on them when they were reported, it did have some downsides.

  • Having a developer assigned to an issue gave an impression that someone was working on the issue. Most of the time, developers are working on only a small number of bugs in the Tracker, so this was potentially sending a false message.
  • If an issue already has an assignee, other developers may be reluctant to volunteer to take on an issue. We want to encourage developers to be involved in resolving issues without impediments.

Issues are no longer automatically assigned to developers as they are reported. Developers should only assign an issue to themselves when they have a definite intention to complete the issue. Components are automatically watched by users and most newly created issues are triaged. This affects the Moodle project only (not Add-ons).

For more information, please see http://docs.moodle.org/dev/Changes_to_issue_assignment

 

Average of ratings: Useful (3)
In reply to Michael de Raadt

Re: Changes to assignment of Tracker issues in the Moodle project

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Michael "You may soon see developers unassigning themselves from issues that they do not intend to work on in the immediate future."

Just a bunch of lazybones, I say.tongueout

Seriously, it seems a good idea.

You write "Some components are automatically watched by users. If you think a user should be involved, add them to the list of watchers and comment on the issue."

1.- By "users" I suppose you mean "developers"?

2.- When we report a new issue (in Moodle core), can a "reporter" no longer manually assign a "developer" to the issue? the recommended policy is to add potential developers as "watchers" only?

3.- For add-ons, does the automatic assignment system continue to exist? If so, why does it not follow suit?

Joseph

In reply to Joseph Rézeau

Re: Changes to assignment of Tracker issues in the Moodle project

by Michael de Raadt -

Hi, Joseph.

Thanks for your questions. Here are some answers...

  1. The component leads are mostly developers, but some aren't.
  2. Issue reporters can potentially still assign developers, but it is not happening automatically.
  3. Currently this change is limited to the Moodle project. We could use a similar system for Add-ons, although component leads there are often working more independently. It can be done on a per-component basis, so if someone wants that in the Add-ons project, I am happy to set it up. In the meantime, it looks like we have some teething problems, so it might be unwise to extend this further.
In reply to Michael de Raadt

Re: Changes to assignment of Tracker issues in the Moodle project

by Rex Lorenzo -

When you say the "immediate future", do you mean only if they intend to work on the issue during the current sprint? Or is it like a 1, 2, 3+ sprint timeline?

Also, we use JIRA as our project management tool and you can set it up so that component leads are automatically assigned as a watcher for an issue? I didn't know that if that is how you are handling component leads now.

In reply to Rex Lorenzo

Re: Changes to assignment of Tracker issues in the Moodle project

by Michael de Raadt -

Hi, Rex.

By "immediate future" I mean about to start working on it. I'm not saying we should police that, but it would be good to give others a chance to work on issues, if possible.

What plugin are you using for automatic watching. The one we have currently is the "Component Watchers" plugin, but that handles watching independently of the normal watchers list, so you can't un-watch an issue if you are the component lead. We are also looking at the "Bug Watcher" plugin, but I haven't played with that yet.

In reply to Michael de Raadt

Re: Changes to assignment of Tracker issues in the Moodle project

by Derek Chirnside -

On a related issue Michael, I noticed a few issues recently (Just last weekend) that just need to be closed.  Need a "Moodle has moved on, no longer relevant" option.

Do you have a preferred approach for this?  Post a note and say "Could close this?"

It's the OCD part of me.  I have great patience for many of the tracker items I'm watching.  Tolerance for ambiguity is part of Moodle life.  But when I see loose ends I like them tied up.

-Derek

In reply to Derek Chirnside

Re: Changes to assignment of Tracker issues in the Moodle project

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

There are a lot like that - just post a comment on the ones you think can be closed... Ideally use the same text or something we could filter on and then ping someone (feel free to ping me) with a link to a filter that lists the particular issues you think can be closed.

In reply to Derek Chirnside

Re: Changes to assignment of Tracker issues in the Moodle project

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Cleaning up old tracker issues is a small but important contribution. It helps developers focus on the issues that are still relevant. As Dan says, if you can't close them yourself (I would tend to use Cannot reproduce as an approximation for Cannot reproduce any more in this case) then add a comment asking someone else to close them.