We can probably improve core development process with some simple improvements:

  • Add a "blocked" status for deadlocked issues
  • Explicitly timebox key issues; A leader would be able to extend the timebox if the conversation was not "done"
  • Develop an assignment process to trusted leaders when the issue has not been able to go forward.
  • Determine committability of an issue/design long before the actual RTBC or commit (and mark it as such). This makes the bikeshed happen (if necessary) well before the final commit point.

Other simple thoughts for core process improvements?

Comments

valthebald’s picture

I think this should not be limited only to core.
Contrib also suffers from dead/stuck issues. Yes, one can launch the project takeover procedure, but it's lengthy and does not always match the one-time patch fixes.

Kjartan’s picture

Short term I think we would be better off using tags for flagging things for now. I'm not sure when or how to get the timebox feature added to d.o. The focus for d.o development will be getting everything upgraded to D7. Its possible this is a simple feature and they could implement it at the same time, but it also seems like a feature that will require a long discussion on the details.

Overall maybe this is a bit premature and should wait until we have a better idea of what small changes we want to implement.

valthebald’s picture

Title: Core dev process improvement (new statuses, etc.) » Dev process improvement (new statuses, etc.)

I dared to change the title (removed Core)

Mile23’s picture

Timeboxing could be 'Decide by' field that triggers a rule that flips the issue status to 'needs work' and assigns it to the project maintainer, ie Dries. That is an example of a run-on sentence.

Mile23’s picture

Issue summary: View changes

Added committability discussion