On Wed, Apr 4, 2018 at 6:48 PM, Brian Bouterse <bbout...@redhat.com> wrote: > The lazy model is lazy, but I don't think it's ineffective. If there are > issues with the lazy consensus model, let's talk about what those are. > Adding a new, second process to-the-side I think will only muddy the water. > > I believe in the benefit of asynchronous decision making for open source > projects. Moving to a single-person role moves us to a centralized decision > making model. There is some related content in this video [0] from fosdem: > "Asynchronous Decision Making -- why and how. How Asynchronous Decision > Making works and why it's essential"
I hope the Technical Leader would weigh in only in case no consensus can be established, be it either on planning (priority) issues or technical issues, it's not about power or control, rather about help. Adopting these roles doesn't necessarily make our life less asynchronous as the role existence doesn't imply more meetings or synchronous activity, or do I miss something? > > [0]: > https://fosdem.org/2018/schedule/event/community_decision_making_why_how/ > > On Wed, Apr 4, 2018 at 12:27 PM, Daniel Alley <dal...@redhat.com> wrote: >>> >>> >>> My opinion is that we have stalled and punted several very important >>> issues when lazy consensus was too lazy. This has slowed our progress enough >>> that I am interested in fleshing out alternatives. >> >> >> +1 >> >> On Wed, Apr 4, 2018 at 11:14 AM, Austin Macdonald <aus...@redhat.com> >> wrote: >>> >>> >>> >>> On Wed, Apr 4, 2018 at 9:01 AM, 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. >>> >>> >>> OpenStack tech leads aren't "single decision makers", they are a fallback >>> for when consensus isn't reached. In theory the role could scope creep to >>> "single decision makers" depending on the style of the individual, but >>> elections prevent that if the voters are responsible. >>> >>>> >>>> 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). >>> >>> >>> A "rotating role" is different than an elected position. I'm not sure >>> what Milan meant by "time boxed", but I imagine this would just be another >>> election, not a term limit. I think if this is done well, it would augment >>> the lazy consensus model, not replace it. >>>> >>>> >>>> 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. >>> >>> >>> +1 We should set this up carefully. I think a PUP is the right way to do >>> that. >>> >>> My opinion is that we have stalled and punted several very important >>> issues when lazy consensus was too lazy. This has slowed our progress enough >>> that I am interested in fleshing out alternatives. >>> >>>> >>>> >>>> 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
