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