+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
