Closed matks closed 3 years ago
kpodemski
commented
3 years ago Voting phase lasts for 2 weeks. Maintainers must vote between the end of the 2 weeks. If maintainers vote quickly, as soon as all maintainers have voted, Voting phase can be ended.
If we discuss something for 2 weeks, why voting phase needs so much time? I'd rather go for something similar to external maintainer verification where we have some time to discuss, we set a date for a vote phase and just vote :)
matks
commented
3 years ago Voting phase lasts for 2 weeks. Maintainers must vote between the end of the 2 weeks. If maintainers vote quickly, as soon as all maintainers have voted, Voting phase can be ended.
If we discuss something for 2 weeks, why voting phase needs so much time? I'd rather go for something similar to external maintainer verification where we have some time to discuss, we set a date for a vote phase and just vote :)
I was thinking about inclusivity.
Imagine if tomorrow you take 10 days of holidays 😉 . The 2 weeks time window aims to make sure that, if a maintainer currently cannot dedicate much of his time to the opensource project ; it does not mean he's excluded from the process.
But this is a "maximum upper limit". When voting starts, if we get all votes within 48 hours the process ends there 😄 it's rather "maintainers can vote within 2 weeks, the process ends either when every vote has been casted or when 2 weeks period is over" .
Is that better this way?
PierreRambaud
commented
3 years ago However it seems it is quite hard for @PrestaShop/prestashop-maintainers to gather time for majority of us to discuss then vote a topic. The result being that we have 8 ADRs waiting right now and most of them are now stale.
It doesn't mean the discussion has to be approved only by people who take time to participate, don't forget an ADR has to be a "maintainers decision".
Two weeks after the beginning of the Discussion phase, if all questions have been answered, we move to Voting Phase. If unanswered questions remain they must be answered by author. After the 2 weeks, as soon as unanswered questions count reaches zero, Voting phase begins.
I'm totally against timeboxing ADR, it's nonsense, even PHP doesn't do that. Most of them started years ago and are still in discussions.
Keep in mind, we have a lot of issues with label "waiting for dev" for months/years and we are not timeboxing them whereas it waits for maintainers' feedbacks, same for pull requests, modules, and many other subjects.
IMHO, the problem with the ADR time is because people who want it fast are not doing many other tasks they should also do, this is why they have time to spend on ADR :wink:
If the ADR needs a fast answer, you're able to ping maintainers on the appropriate community slack channel. But forcing it by time is not a good idea.
matks
commented
3 years ago Hi @PierreRambaud thank your for answering!
I too do not like timeboxing. This is the only idea however that I found which solves efficiently the need for the ADR to reach out a decision.
ADRs usually respond to a need. I don't know for PHP, but I think most of our ADRs, if not answered within a few months, will become useless.
For example the ADR about constants for configuration variables currently prevents the usage of constants for configuration variables. The need is for the refactoring of Configuration forms. If the ADR is answered in 2 years, it is likely the forms will be done by this time and the developer who needed a decision is long gone 😅 .
This is why I don't think "let's keep the process at is today" is a viable answer. Current process has been failing us for 2 years, why would it currently become better?
However if my solution seems too "brutal" I am open to improve it 👍 the idea of the "veto" was added thanks to suggestions of other maintainers for example. And we can also completely drop my suggestion if you have something else we can try and that look promising 😃 .
What I ask, please, is to try: let's have an agile mindset. Current process does not seem to work? Let's try something else on a relevant period of time. If it does not work too, let's try something else. Iteration is a great way to find the appropriate process for a given challenge.
They say that long-lasting couples rely on comprimising: each side must be willing to give up part of their demand. 😉 Please listen to what I say, see the current ADRs being stale, and let's find something in-between your suggestion and my suggestion, and start with that? ❤️
matks
commented
3 years ago Closing as finally we won't follow this path. We discussed it with maintainers and it does not seem a good idea after all.
We decided to start using ADR for 2 purposes
However it seems it is quite hard for @PrestaShop/prestashop-maintainers to gather time for majority of us to discuss then vote a topic. The result being that we have 8 ADRs waiting right now and most of them are now stale.
"ADRs need a voting phase" means "ADRs need most of maintainers to dedicate some of their little time to this topic". And we all know that time is the thing we lack the most 😢 .
I suggest we look forward to improve our ADR process. I have a suggestion, it does not have to be this one we can find alternatives.
Suggestion for timeboxing ADRs
This suggestion has been improved by the feedback from other maintainers. The concept is to timebox ADR process.
1) When an ADR is submitted and accepted, a Discussion phase starts. People can discuss, explore and ask questions about the ADR. Author must answer.
2) Two weeks after the beginning of the Discussion phase, if all questions have been answered, we move to Voting Phase. If unanswered questions remain they must be answered by author. After the 2 weeks, as soon as unanswered questions count reaches zero, Voting phase begins.
If the ADR is very easy or simple, upon majority agreement, Discussion phase can also be shortened.
3) Maintainers have a Veto power to block an ADR if they feel this is being rushed. When Discussion phase reaches end, a maintainer can express his worries about a topic and ask for extension of the Discussion phase.
4) The author can also say from the start that his ADR is complex and require a longer Discussion phase, like 4 or 6 weeks. Regular and scoped ADR have a Discussion phase of 2 weeks by default.
5) Voting phase lasts for 2 weeks. Maintainers must vote between the end of the 2 weeks. If maintainers vote quickly, as soon as all maintainers have voted, Voting phase can be ended.
These rules would ensure that on average have a decision about an ADR 4 weeks later. 1 month seems to be a good compromise between ability to think it through and ability to move on. Items 3 and 4 aim to prevent complex ADRs to be rushed.
We already discussed this in the Slack area.
Remark: this is inspired by PHP RFC process:
Remark 2: we would like to find a good polling system that suits our open source needs but we have not found it yet 😅