Moodle
  1. Moodle
  2. MDL-39214

POLICY: It is too difficult to get decisions on policy questions

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: None
    • Component/s: Policy
    • Labels:
      None
    • Affected Branches:
      MOODLE_24_STABLE
    • Rank:
      46755

      Description

      I have had two bugs in the last few months (MDL-31519 and MDL-35111) where I submitted a valuable bug fix for integration, and it got pushed back with a comment like

      We are not sure if this is the right general approach, there needs to a general policy on how to do this sort of thing, and then we will know whether to accept or reject your patch. In the mean time, we are going to take it out of integration.

      The problem is, nothing happens after that.

      Who should make those policy decision? What is the process for doing so?

      It is not quite the same as coding style, where we have the policy "Create a MDLSITE, then the integrators decide".

      Meanwhile, those patches I made which fix a problem that is causing pain to Moodle users just sit there bit-rotting.

        Issue Links

          Activity

          Hide
          Tim Hunt added a comment -

          Adding Michael and Martin as watchers.

          Rather than just complaining, here is my proposed solution:

          1. Integrator is worried about the general policy implications of a patch.
          2. Integrator discusses the patch with other integrators, and the developer / peer reviewer, to see if the worry is real (in which case continue) or whether it can be resolved as part of the normal weekly integration cycle (in which case stop this process.)
          3. We now have a genuine issue that needs to be discussed and decided. The integrator creates a MDLSITE / Coding style issue, that summarises the question to be decided, and links it to the original issue.
          4. Integrator posts in General developer forum, and any other relevant forum (e.g. Themes in some cases) to highlight the issue and ask for opinions and discussion.
          5. Integration of the bug fix that started this is put on hold.
          6. In time, hopefully a consensus is reached among the community. If that does not happen after some time, the integrators decide the matter amongst themselves.
          7. Once the policy is decided, the original issue is either re-submitted for integration, or re-worked and then re-submitted.

          I think we should allow a variation on step 5. If the problem is serious enough, we may decided to integrate the fix immediately, to solve the user's problems. If that is done, then the Integrator should file a new MDL-new bug saying "Rework the fix for MDL-old if necessary once the the issue MDLSITE-... has been decided."

          Show
          Tim Hunt added a comment - Adding Michael and Martin as watchers. Rather than just complaining, here is my proposed solution: Integrator is worried about the general policy implications of a patch. Integrator discusses the patch with other integrators, and the developer / peer reviewer, to see if the worry is real (in which case continue) or whether it can be resolved as part of the normal weekly integration cycle (in which case stop this process.) We now have a genuine issue that needs to be discussed and decided. The integrator creates a MDLSITE / Coding style issue, that summarises the question to be decided, and links it to the original issue. Integrator posts in General developer forum, and any other relevant forum (e.g. Themes in some cases) to highlight the issue and ask for opinions and discussion. Integration of the bug fix that started this is put on hold. In time, hopefully a consensus is reached among the community. If that does not happen after some time, the integrators decide the matter amongst themselves. Once the policy is decided, the original issue is either re-submitted for integration, or re-worked and then re-submitted. I think we should allow a variation on step 5. If the problem is serious enough, we may decided to integrate the fix immediately, to solve the user's problems. If that is done, then the Integrator should file a new MDL-new bug saying "Rework the fix for MDL-old if necessary once the the issue MDLSITE-... has been decided."
          Hide
          Dan Poltawski added a comment -

          I agree that this is a problem (if nothing else but the fact we don't even record the need to make a decision so can often get lost). The other problem is finding a good place to document these policies. Its relatively simple for the coding style because things fit together well. But these broader 'how Moodle should work' type policies are scattered around information. It'd be good if we could find a way to record these things in a place as easy to document as the coding style. (And I mean that in the short term so we could start doing it now).

          Show
          Dan Poltawski added a comment - I agree that this is a problem (if nothing else but the fact we don't even record the need to make a decision so can often get lost). The other problem is finding a good place to document these policies. Its relatively simple for the coding style because things fit together well. But these broader 'how Moodle should work' type policies are scattered around information. It'd be good if we could find a way to record these things in a place as easy to document as the coding style. (And I mean that in the short term so we could start doing it now).
          Hide
          Martin Dougiamas added a comment -

          I think "In time, hopefully a consensus is reached among the community." is the sticking point.

          How about one new forum on moodle.org, visible from the front page on the new site, called something like "Help guide the future of Moodle" with one policy issue per discussion. Subjects could be prefixed with "DEVELOPERS: ", "USERS: " or "ALL: "

          It would be something parallel (and sometimes a precursor) to the new features forum we started which is more about major features and technical decisions and progress within that.

          Show
          Martin Dougiamas added a comment - I think "In time, hopefully a consensus is reached among the community." is the sticking point. How about one new forum on moodle.org, visible from the front page on the new site, called something like "Help guide the future of Moodle" with one policy issue per discussion. Subjects could be prefixed with "DEVELOPERS: ", "USERS: " or "ALL: " It would be something parallel (and sometimes a precursor) to the new features forum we started which is more about major features and technical decisions and progress within that.
          Hide
          Tim Hunt added a comment -

          Thank you for considering this.

          @Dan, sitting one level above http://docs.moodle.org/dev/Coding_style we have http://docs.moodle.org/dev/Coding (which really needs some love) to document other aspects of how Moodle code is supposed to work, of which "how to lay out your code" is really the most trivial point. These sorts of policy decisions could probably be made to fit in there (under architecture?) with a bit of reorganisation.

          @Martin, to be honest, we have no idea whether it will be a sticking point or not, because we have rarely tried to do it, at least in recent times. Actually, I have started some threads like that in the themes forum, and typically one of two things happens: either you quickly get a consensus, or you realise that things are much more complex than you though, in which case the best bet is to shelve things for now.

          Given Helen and Dan's recent hard work on forum rationalisation, I think a new forum is the last thing we need. Better to take the discussion to the Moodlers, than to make the Moodlers come to the discussion. I think we should use the General Developers Forum for DEVELOPERS: ones, and Major new features for the USERS: or ALL: ones. After all, it is not as if Major new features is overwhelmed by traffic. If you like, you can prefix these discussions with DECISION NEEDED: or something.

          Show
          Tim Hunt added a comment - Thank you for considering this. @Dan, sitting one level above http://docs.moodle.org/dev/Coding_style we have http://docs.moodle.org/dev/Coding (which really needs some love) to document other aspects of how Moodle code is supposed to work, of which "how to lay out your code" is really the most trivial point. These sorts of policy decisions could probably be made to fit in there (under architecture?) with a bit of reorganisation. @Martin, to be honest, we have no idea whether it will be a sticking point or not, because we have rarely tried to do it, at least in recent times. Actually, I have started some threads like that in the themes forum, and typically one of two things happens: either you quickly get a consensus, or you realise that things are much more complex than you though, in which case the best bet is to shelve things for now. Given Helen and Dan's recent hard work on forum rationalisation, I think a new forum is the last thing we need. Better to take the discussion to the Moodlers, than to make the Moodlers come to the discussion. I think we should use the General Developers Forum for DEVELOPERS: ones, and Major new features for the USERS: or ALL: ones. After all, it is not as if Major new features is overwhelmed by traffic. If you like, you can prefix these discussions with DECISION NEEDED: or something.
          Hide
          Tim Hunt added a comment -

          I was just reminded of this. When do you think any decisions are going to be made here?

          Show
          Tim Hunt added a comment - I was just reminded of this. When do you think any decisions are going to be made here?
          Hide
          Tim Hunt added a comment -

          And another one to add to the list MDL-37178.

          Show
          Tim Hunt added a comment - And another one to add to the list MDL-37178 .
          Hide
          Eloy Lafuente (stronk7) added a comment -

          it's not difficult. just let me decide and you will see.

          Show
          Eloy Lafuente (stronk7) added a comment - it's not difficult. just let me decide and you will see.
          Hide
          Eric Merrill added a comment -

          I feel like this decision on how to resolve this problem is going to stall out. Hopefully MDLSITE-2042 will provide some direction on how to make this decision.

          Show
          Eric Merrill added a comment - I feel like this decision on how to resolve this problem is going to stall out. Hopefully MDLSITE-2042 will provide some direction on how to make this decision.
          Hide
          Dan Poltawski added a comment -

          It feels appropriate to reassign this..

          Show
          Dan Poltawski added a comment - It feels appropriate to reassign this..
          Hide
          Martin Dougiamas added a comment -

          Here's a policy: if in doubt, leave it out.

          I'm actually happy to let the integrators vote on such things almost all of time, and if they deadlock I am happy to cast a final vote.

          Show
          Martin Dougiamas added a comment - Here's a policy: if in doubt, leave it out. I'm actually happy to let the integrators vote on such things almost all of time, and if they deadlock I am happy to cast a final vote.
          Hide
          Tim Hunt added a comment -

          I would be very happy if the integrators did decide such things. The problem is the integrators say "We can't integrate this, something needs to be decided." And then nothing is decided. For months. The original two issues I gave: (MDL-31519 and MDL-35111) are bugs. Something is broken, and no one will tell me what the right way to fix it is, nor will the integrate a temporary fix in the mean time.

          Show
          Tim Hunt added a comment - I would be very happy if the integrators did decide such things. The problem is the integrators say "We can't integrate this, something needs to be decided." And then nothing is decided. For months. The original two issues I gave: ( MDL-31519 and MDL-35111 ) are bugs. Something is broken, and no one will tell me what the right way to fix it is, nor will the integrate a temporary fix in the mean time.
          Hide
          Michael de Raadt added a comment -

          Yes, it's hard to commit developers to a task that may or may not be integrated. Apart from a potential waste of time, it really doesn't help to be creating solutions with uncertainty.

          Show
          Michael de Raadt added a comment - Yes, it's hard to commit developers to a task that may or may not be integrated. Apart from a potential waste of time, it really doesn't help to be creating solutions with uncertainty.
          Hide
          Dan Poltawski added a comment -

          > it's hard to commit developers to a task that may or may not be integrated.

          I really think that 90% of tasks should not have that uncertainty, and to experienced moodle devs i'd argue they don't (we know what to steer clear of ). If the code is good, the performance is unaffected, the community are on board, there isn't duplicated code then it'll be accepted most of the time. Too much of the time not all those factors are taken into consideration and then fall down at the first hurdle.

          Where I think it becomes difficult to predict are historial issues, e.g. from my experience I know that this problem X has gone round and round 10 times in the past and its not as simple as you think. That is probably the most frustrating part for developers, but for me, its the most valuable thing we do as integrators. We're being the human history which stops us repeating the same mistake again and again, and if there was a way for developers to predict it then it'd be pointless wasting so much human resources on this. For those situations I think that you need to consider letting people uncommit from issues. That may be conflicting with scrum, but I think that we will benefit our users, moodle partners etc better if we sometimes choose not to fix an issue, rather than continue to work on something which will take a lot of time for little gain. We could fix 10 other issues instead.

          I think this is a different problem to what Tim is talking to though, because I know the sort of issues which Tim reffers to, and its the point where I as an integrator am not confident of what the way forward is. A great example I can think off the top of my head is the conflicting views on what should happen to student data on unenrollment..

          In the integration team I feel we've been getting better at sharing, voting and proceeding with issues like the backports. Maybe we could consider some sort of formal 'needs policy call' state and define a way to move things forward like tim proposed. I'm not that comfortable with us making all these kind of calls though. It feels like there should be a way of doing this from the community and only fall back to us/martin if in deadlock. So we need a process, timelines and deadlock resolution.

          Show
          Dan Poltawski added a comment - > it's hard to commit developers to a task that may or may not be integrated. I really think that 90% of tasks should not have that uncertainty, and to experienced moodle devs i'd argue they don't (we know what to steer clear of ). If the code is good, the performance is unaffected, the community are on board, there isn't duplicated code then it'll be accepted most of the time. Too much of the time not all those factors are taken into consideration and then fall down at the first hurdle. Where I think it becomes difficult to predict are historial issues, e.g. from my experience I know that this problem X has gone round and round 10 times in the past and its not as simple as you think. That is probably the most frustrating part for developers, but for me, its the most valuable thing we do as integrators. We're being the human history which stops us repeating the same mistake again and again, and if there was a way for developers to predict it then it'd be pointless wasting so much human resources on this. For those situations I think that you need to consider letting people uncommit from issues. That may be conflicting with scrum, but I think that we will benefit our users, moodle partners etc better if we sometimes choose not to fix an issue, rather than continue to work on something which will take a lot of time for little gain. We could fix 10 other issues instead. I think this is a different problem to what Tim is talking to though, because I know the sort of issues which Tim reffers to, and its the point where I as an integrator am not confident of what the way forward is. A great example I can think off the top of my head is the conflicting views on what should happen to student data on unenrollment.. In the integration team I feel we've been getting better at sharing, voting and proceeding with issues like the backports. Maybe we could consider some sort of formal 'needs policy call' state and define a way to move things forward like tim proposed. I'm not that comfortable with us making all these kind of calls though. It feels like there should be a way of doing this from the community and only fall back to us/martin if in deadlock. So we need a process, timelines and deadlock resolution.
          Hide
          Eric Merrill added a comment -

          I definitely agree that there should be some form of a label or even a full on ticket status for tickets pending some form of policy decision. While I will say it has been getting better, it still happens that a ticket gets bounced back (either from peer review or integration) with a comment along the lines of "I think there needs to be a broader discussion about how to fix this", or "we need to decide what our policy is with this" and then it just dies there, with the ticket languishing forever (basically). Right now, seemingly, the only way to resurrect these tickets is to find the right people to bug off-tracker, which just doesn't feel proper. If there was a way to mark these tickets, and that marking was monitored by HQ, I think it would be much more likely that these items wouldn't just disappear into ticket limbo.

          Show
          Eric Merrill added a comment - I definitely agree that there should be some form of a label or even a full on ticket status for tickets pending some form of policy decision. While I will say it has been getting better, it still happens that a ticket gets bounced back (either from peer review or integration) with a comment along the lines of "I think there needs to be a broader discussion about how to fix this", or "we need to decide what our policy is with this" and then it just dies there, with the ticket languishing forever (basically). Right now, seemingly, the only way to resurrect these tickets is to find the right people to bug off-tracker, which just doesn't feel proper. If there was a way to mark these tickets, and that marking was monitored by HQ, I think it would be much more likely that these items wouldn't just disappear into ticket limbo.
          Hide
          Tim Hunt added a comment -

          Thinking about this at a time when I am less pissed off with the world, I realised that this should take us back to Moodle's social constructionst roots.

          Where we hit one of these difficult problem, then we as the Moodle community need to learn the answer by talking to each other. Now, there are two cases here:

          1. If it is an issue that I, or the OU, cares about, then I will be motivated to start a forum thread, and moderate a discussion the reaches a consensus that I am happy to implement (or alternatively give up my plans if a consensus cannot be reached.)

          2. If it is some issue that has come to me as Quiz moderator, and I am only trying to fix it because I and the OU are nice people, and then I hit one of these problems, then I probably don't have the time or motivation to get a consensus.

          2b. It is particularly irritating when I have already made a patch which I think falls into the "90% of tasks should not have that uncertainty, and to experienced moodle devs i'd argue they don't" situation, and it is only the integrator who thinks there is a problem.

          In case 2. I think it has to be someone at Moodle HQ who facilitates the consensus building, becuase that is where the buck stops for problems that no-one else cares about.

          I think it is under-using the power of the community to expect the integrators to solve these problems behind closed doors. It is likely to be better all round to discuss them in the general developer forum.

          Of course, there are other, simpler issues, like coding style, where just getting the integrators to decide is the right solution, but the kind of policy decisions we are considering here are nuclear reactors, not bike sheds.

          Show
          Tim Hunt added a comment - Thinking about this at a time when I am less pissed off with the world, I realised that this should take us back to Moodle's social constructionst roots. Where we hit one of these difficult problem, then we as the Moodle community need to learn the answer by talking to each other. Now, there are two cases here: 1. If it is an issue that I, or the OU, cares about, then I will be motivated to start a forum thread, and moderate a discussion the reaches a consensus that I am happy to implement (or alternatively give up my plans if a consensus cannot be reached.) 2. If it is some issue that has come to me as Quiz moderator, and I am only trying to fix it because I and the OU are nice people, and then I hit one of these problems, then I probably don't have the time or motivation to get a consensus. 2b. It is particularly irritating when I have already made a patch which I think falls into the "90% of tasks should not have that uncertainty, and to experienced moodle devs i'd argue they don't" situation, and it is only the integrator who thinks there is a problem. In case 2. I think it has to be someone at Moodle HQ who facilitates the consensus building, becuase that is where the buck stops for problems that no-one else cares about. I think it is under-using the power of the community to expect the integrators to solve these problems behind closed doors. It is likely to be better all round to discuss them in the general developer forum. Of course, there are other, simpler issues, like coding style, where just getting the integrators to decide is the right solution, but the kind of policy decisions we are considering here are nuclear reactors, not bike sheds.
          Hide
          Tim Hunt added a comment -

          Just linking MDL-37993, another issue that throws up a policy question: Should later changes to activity settings retroactively affect activity completion state?

          Show
          Tim Hunt added a comment - Just linking MDL-37993 , another issue that throws up a policy question: Should later changes to activity settings retroactively affect activity completion state?
          Hide
          Ray Morris added a comment - - edited

          > I'm actually happy to let the integrators vote on such things almost all of time,
          > and if they deadlock I am happy to cast a final vote.

          Is there a process for that? For example, the issue Tim linked to, MDL-37993 , has been discussed in the tracker and the forum. Is there a process to now submit the question to the integrators?
          How do we get to "I am happy to cast the final vote"?

          MDL-37993 is a great example. We need to pick between option "A" and option "B". Even though Tim and I have opposite ideas of which is best, I think we agree that worse than either would be to bring development to a halt indefinitely because we have no way to make a decision.

          If no such process exists, a BDFL ala Torvalds might be useful at times.

          Show
          Ray Morris added a comment - - edited > I'm actually happy to let the integrators vote on such things almost all of time, > and if they deadlock I am happy to cast a final vote. Is there a process for that? For example, the issue Tim linked to, MDL-37993 , has been discussed in the tracker and the forum. Is there a process to now submit the question to the integrators? How do we get to "I am happy to cast the final vote"? MDL-37993 is a great example. We need to pick between option "A" and option "B". Even though Tim and I have opposite ideas of which is best, I think we agree that worse than either would be to bring development to a halt indefinitely because we have no way to make a decision. If no such process exists, a BDFL ala Torvalds might be useful at times.
          Hide
          Martin Dougiamas added a comment -

          OK, so looking at MDL-37993 the first problem is to understand what options A and B mean. Until we have clear data no-one can really decide.

          Thanks also to all for the ideas above.

          I think the process could be something like this:

          1) Produce a summary document in Moodle Dev Docs that explains the options and exhaustive list of pros and cons for each choice.

          2) Create a new issue in a new category in the tracker called "Policy", with perhaps an subject starting with POLICY: and link to that doc. Post also in relevant forums to raise awareness.

          3) Integrators and myself will be looking for these issues and we discuss, look for consensus and resolve. Of course anyone can comment on the issue at any time if they want to add perspectives. We would allocate some time on these at our weekly HQ meetings to make sure such issues are usually dealt with quickly. The decision is then laser-etched into a solid block of platinum and stored inside a glacier for eternity.

          We did something like this in MDL-38322 for example.

          In fact to avoid holding this up further I'm going to say this is now the proper way to do it. If you don't like it: file a new policy issue with other options.

          Show
          Martin Dougiamas added a comment - OK, so looking at MDL-37993 the first problem is to understand what options A and B mean. Until we have clear data no-one can really decide. Thanks also to all for the ideas above. I think the process could be something like this: 1) Produce a summary document in Moodle Dev Docs that explains the options and exhaustive list of pros and cons for each choice. 2) Create a new issue in a new category in the tracker called "Policy", with perhaps an subject starting with POLICY: and link to that doc. Post also in relevant forums to raise awareness. 3) Integrators and myself will be looking for these issues and we discuss, look for consensus and resolve. Of course anyone can comment on the issue at any time if they want to add perspectives. We would allocate some time on these at our weekly HQ meetings to make sure such issues are usually dealt with quickly. The decision is then laser-etched into a solid block of platinum and stored inside a glacier for eternity. We did something like this in MDL-38322 for example. In fact to avoid holding this up further I'm going to say this is now the proper way to do it. If you don't like it: file a new policy issue with other options.
          Hide
          Damyon Wiese added a comment -

          2c from me. Integrating a temporary workaround issue for an issue that needs a clear policy creates confusion and more work later on - people will copy the code used in the workaround and it will become the defacto standard.

          Show
          Damyon Wiese added a comment - 2c from me. Integrating a temporary workaround issue for an issue that needs a clear policy creates confusion and more work later on - people will copy the code used in the workaround and it will become the defacto standard.
          Hide
          Ray Morris added a comment -

          This issue has not been corrected. We still have policy issues sitting for a year or more waiting for a response from HQ. This is after doc pages have been written up, etc. - issues still get no response and bit rot results as code languishes awaiting simple policy decisions.

          Show
          Ray Morris added a comment - This issue has not been corrected. We still have policy issues sitting for a year or more waiting for a response from HQ. This is after doc pages have been written up, etc. - issues still get no response and bit rot results as code languishes awaiting simple policy decisions.

            People

            • Votes:
              10 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: