[Pulp-dev] Improving technical decision making

Brian Bouterse bbouters at redhat.com
Wed Apr 4 16:48:50 UTC 2018


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.
Adding a new, second process to-the-side I think will only 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_making_why_how/

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/a8bd6424/attachment.htm>


More information about the Pulp-dev mailing list