Page History

...

After three days, one mentor, who had been travelling, objected, saying the merge introduced licensing complications. By then, the code had already been merged and discussed in other channels. The mentor felt ignored, while the community felt blindsided by the late objection. The thread devolved into arguments about whether the decision was final and who had the right to reopen it.

Reflection questions

1. What went wrong in this case, and how could the podling have avoided misunderstanding around caused confusion about the lazy consensus process?
2. How should the mentor and community handle objections that arise after a decision has been acted uponcommunity respond when an objection comes after action has been taken?

Possible path forward

• Reopen discussion to consider the objection and, if needed, revert the change.
• In future, clearly state objection periods and follow up with a “no objections received” message to confirm consensus
• Reconfirm the change by summarizing the objection and reopening the discussion on the mailing list.
• Clarify future lazy consensus procedures by defining objection windows clearly (e.g., “no objections within 72 hours”) and sending a follow-up summary email stating when consensus was reached.
• Mentors can model good practice by posting clear “no objections received” messages when lazy consensus concludeskeeping both decisions and closures visible on the mailing list.

...

Scenario: Ambiguous Vote Scope

...