+1 to Ina's two points.  Knowledge sharing helps increase team ownership in
the whole of the project instead of "oh that's A's job."

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Tue, Apr 10, 2018 at 7:56 PM, Ina Panova <ipan...@redhat.com> wrote:

> 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 <bbout...@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 <mkova...@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 <mkova...@redhat.com>
>>> wrote:
>>> > On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald <aus...@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 <mkova...@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 <bbout...@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 <
>>> aus...@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@redhat.com
>>> >>> > https://www.redhat.com/mailman/listinfo/pulp-dev
>>> >>> >
>>> >>
>>> >>
>>>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Reply via email to