[Pulp-dev] Improving technical decision making

Tue Apr 10 23:56:11 UTC 2018

I could see some advantages here.
The benefit of such proposal could create a healthy ecosystem in our team.
We just need to answer the question whether now or later is a more
appropriate time.

I do understand that not everyone on our team has same level of expertise
and soft skills, but with these rotation we can:
1) do knowledge transfer, this way less experienced person will learn from
a more experienced.
2) the ecosystem of our team will be healthy, and we will not panic when
that single person that knows X is not PTO and he have sev1 issue or
similar.

--------
Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Wed, Apr 4, 2018 at 3:01 PM, 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. 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).
>
> 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.
>
>
> 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/20180411/f3ee0758/attachment.htm>