[Pulp-dev] Improving technical decision making

Wed Apr 4 21:57:46 UTC 2018

On Wed, Apr 4, 2018 at 12:48 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> The lazy model is lazy, but I don't think it's ineffective. If there are
> issues with the lazy consensus model, let's talk about what those are.
>

I dub this problem the "lazy veto". If there is a choice is between "do
something" and "don't do something" anyone who is -1 does not have an
incentive to engage in discussion. "Default to punt" is the opposite of our
intention, which we agreed was "default to change".

> Adding a new, second process to-the-side I think will only muddy the water.
>

The idea is that a good tech lead would only act when there is a stalled
decision. How could that muddy the water?

> I believe in the benefit of asynchronous decision making for open source
> projects. Moving to a single-person role moves us to a centralized decision
> making model. There is some related content in this video [0] from fosdem:
> "Asynchronous Decision Making -- why and how. How Asynchronous Decision
> Making works and why it's essential"
>
> [0]: https://fosdem.org/2018/schedule/event/community_decision_ma
> king_why_how/
>

I watched the video, and it was interesting. Whether we move forward with a
tech lead, or a voting system, or whatever, we must have an official
process.

>
>
On Wed, Apr 4, 2018 at 12:27 PM, Daniel Alley <dalley at redhat.com> wrote:
>
>>
>>> My opinion is that we have stalled and punted several very important
>>> issues when lazy consensus was too lazy. This has slowed our progress
>>> enough that I am interested in fleshing out alternatives.
>>>
>>
>> +1
>>
>> On Wed, Apr 4, 2018 at 11:14 AM, Austin Macdonald <austin at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 9:01 AM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>> I'm not ready to pursue a single decision maker model for Pulp's
>>>> technical decisions or community leadership.
>>>>
>>>
>>> OpenStack tech leads aren't "single decision makers", they are a
>>> fallback for when consensus isn't reached. In theory the role *could *scope
>>> creep to "single decision makers" depending on the style of the individual,
>>> but elections prevent that if the voters are responsible.
>>>
>>>
>>>> I also have concerns about those positions being rotating roles since
>>>> typically they require much experience. This would also be a departure from
>>>> the lazy consensus decision making model we use for community decisions
>>>> (the pup process itself).
>>>>
>>>
>>> A "rotating role" is different than an elected position. I'm not sure
>>> what Milan meant by "time boxed", but I imagine this would just be another
>>> election, not a term limit. I think if this is done well, it would augment
>>> the lazy consensus model, not replace it.
>>>
>>>>
>>>> There would need to be a lot of discussion with input from many people
>>>> around what the issues currently are so we can be sure that changes would
>>>> resolve those issues.
>>>>
>>>
>>> +1  We should set this up carefully. I think a PUP is the right way to
>>> do that.
>>>
>>> My opinion is that we have stalled and punted several very important
>>> issues when lazy consensus was too lazy. This has slowed our progress
>>> enough that I am interested in fleshing out alternatives.
>>>
>>>
>>>>
>>>> On Wed, Apr 4, 2018 at 4:54 AM, Milan Kovacik <mkovacik at redhat.com>
>>>> wrote:
>>>>
>>>>> Oh I'd forget that we actually don't really have a formal process to
>>>>> recognize and retire active contributors yet;
>>>>> how about the technical lead proposes both the recognition and
>>>>> retirement anytime they find reason to do so, for the former
>>>>> situation, with a pre-approval of  other active contributors, propose
>>>>> folks publicly, for the latter situation, try reaching out to the
>>>>> retiring contributor before going public to avoid frustration.
>>>>> Folks of course would ideally announce their intention to retire, the
>>>>> formal process would be conducted by the technical lead.
>>>>> The insignia of an active contributor would be the commit bit on any
>>>>> of the Pulp projects.
>>>>> The first ever technical and community leads would be elected by folks
>>>>> with the commit bit, the election would be organized by our current
>>>>> community representatives.
>>>>>
>>>>> Unless there are objections, I'd file a PUP to summarize these points.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> milan
>>>>>
>>>>> On Tue, Apr 3, 2018 at 6:02 PM, Milan Kovacik <mkovacik at redhat.com>
>>>>> wrote:
>>>>> > On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald <austin at redhat.com>
>>>>> wrote:
>>>>> >> Interesting proposals Milan!
>>>>> >>
>>>>> >> I am forking Brian's email so that thread can focus on
>>>>> communication,
>>>>> >> redmine, etc.
>>>>> >
>>>>> > Thanks, I guess it would best go hand-in-hand with the process update
>>>>> > proposal for the Technical specifications/blue-prints PUP:
>>>>> >
>>>>> >>> I'd add that many a time, an e-mail based technical discussion gets
>>>>> >>> messy and unfolds in multiple branches over multiple months.
>>>>> >>> I'd like to propose we adopt a Technical Specification concept,
>>>>> living
>>>>> >>> in a separate GitHub repo, similar to the PUP process.
>>>>> >>> This would take advantage of our review process, preferably
>>>>> requiring
>>>>> >>> multiple (core) reviewers acks before merging, allowing Redmine to
>>>>> be
>>>>> >>> used for planning/tracking the (design) work.
>>>>> >>> I think it's easier to manage the life-cycle of  a larger Technical
>>>>> >>> Specification in a revision system document than an e-mail thread
>>>>> and
>>>>> >>> a single Redmine issue.
>>>>> >>> It also helps (feature) documentation and provides context.
>>>>> >
>>>>> >>
>>>>> >> On Tue, Apr 3, 2018 at 8:13 AM, Milan Kovacik <mkovacik at redhat.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> I'd also like to propose formal Project Technical Lead and a formal
>>>>> >>> Project Community Lead roles to be able to decide in case of
>>>>> competing
>>>>> >>> (technical) ideas or planning priorities.
>>>>> >>> These would have to be time-boxed (half a year) and folks would
>>>>> elect
>>>>> >>> the leader for a period based on leader's program, such as focus on
>>>>> >>> particular goals for instance testing or refactoring.
>>>>> >>> Any single person would be able to perform either the Community or
>>>>> the
>>>>> >>> Technical Lead role in any given period but not both at the same
>>>>> time.
>>>>> >>> The Community Lead role would take care for organizing the
>>>>> Technical
>>>>> >>> Lead elections and vice versa, the Technical Lead would take care
>>>>> >>> about organizing the Community Lead elections.
>>>>> >>> The electorate would be the active contributors for both the roles.
>>>>> >>> The candidates would be the active contributors too.
>>>>> >>>
>>>>> >>> This would open up the decision making process for anyone from the
>>>>> >>> community, would encourage transparency, accountability and
>>>>> >>> responsibility and would allow us to come to a decision on
>>>>> competing
>>>>> >>> (technical) ideas or planning issues in case we'd got stuck.
>>>>> >>>
>>>>> >>> Cheers,
>>>>> >>> milan
>>>>> >>>
>>>>> >>> On Mon, Apr 2, 2018 at 8:38 PM, Brian Bouterse <
>>>>> bbouters at redhat.com>
>>>>> >>> wrote:
>>>>> >>> > I agree the decision process for core itself needs discussion.
>>>>> For now,
>>>>> >>> > I'm
>>>>> >>> > only able to offer facilitating a convo that focuses on the
>>>>> >>> > communication
>>>>> >>> > aspects not the decision process. I would like to improve the
>>>>> >>> > transparency
>>>>> >>> > into the features that will and won't be in any given release
>>>>> for our
>>>>> >>> > stakeholders. I hope we do discuss decision process as its own
>>>>> >>> > discussion;
>>>>> >>> > it's certainly deserving of a pup of its own.
>>>>> >>> >
>>>>> >>> > For the communication issues, soon I will share a basic outline
>>>>> of one
>>>>> >>> > way
>>>>> >>> > we could use Redmine for release planning. This would be a
>>>>> starter idea
>>>>> >>> > towards a solution for us to modify together.
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald <
>>>>> austin at redhat.com>
>>>>> >>> > wrote:
>>>>> >>> >>
>>>>> >>> >> I agree with the problems that Brian listed, but I hope we can
>>>>> focus on
>>>>> >>> >> the decision making process itself in addition to how those
>>>>> decisions
>>>>> >>> >> are
>>>>> >>> >> communicated.
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > _______________________________________________
>>>>> >>> > Pulp-dev mailing list
>>>>> >>> > Pulp-dev at redhat.com
>>>>> >>> > https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>> >>> >
>>>>> >>
>>>>> >>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180404/2ae2fc55/attachment.htm>