[Pulp-dev] Improving technical decision making

[Milan Kovacik]

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
>>> >
>>
>>