On Wed, Apr 4, 2018 at 12: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. > I dub this problem the "lazy veto". If there is a choice is between "do something" and "don't do something" anyone who is -1 does not have an incentive to engage in discussion. "Default to punt" is the opposite of our intention, which we agreed was "default to change". > Adding a new, second process to-the-side I think will only muddy the water. > The idea is that a good tech lead would only act when there is a stalled decision. How could that 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_ma > king_why_how/ > I watched the video, and it was interesting. Whether we move forward with a tech lead, or a voting system, or whatever, we must have an official process. > > 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
