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" [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
