On Mon, Jul 19, 2021 at 11:23 PM Andreas Heigl <andr...@heigl.org> wrote:
> Hey All > > Am 19.07.21 um 17:02 schrieb Andreas Heigl: > > Hey All > > > > Am 19.07.21 um 16:34 schrieb Levi Morrison via internals: > >> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov <nikita....@gmail.com> > wrote: > >>> > >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm <tobias.nyh...@gmail.com > > > >>> wrote: > >>> > >>>> Hey. > >>>> I would like to get karma to be able to vote on RFCs. I understand > that > >>>> voting karma isn’t usually given out to people who write their first > >>>> mailing list entry. > >>>> > >>>> But I do believe I qualify as “Lead developers of PHP based projects > >>>> (frameworks, cms, tools, etc.)” > >>> > >>> Hey Tobias, > >>> > >>> My response here is basically the same as the last time the topic came > up: > >>> https://externals.io/message/110936#110937 Voting is just the very > last > >>> step of the RFC process, at which point the proposal can no longer be > >>> influenced. If you have feedback about a proposal based on your > extensive > >>> experience in PHP's open source ecosystem, then the discussion phase > is the > >>> time to provide it, while it can still influence the proposal, as well > as > >>> other people's view of the proposal. > >> > >> I second this. > >> > >>> At least in my personal opinion, I think it's important that people > granted > >>> voting rights as community representatives have at least some > historical > >>> involvement in RFC discussions. > >> > >> I agree with this, but have no specific objection to granting Tobias > >> voting karma, as this is underspecified; how long should they > >> participate? What kinds of involvement are appropriate? Being > >> underspecified is not really their fault, and I don't feel like it > >> would be an abuse to grant them voting karma, but do think it would be > >> an abuse to deny them voting karma indefinitely because "we" don't get > >> around to specifying it. It should be less of a decision on a > >> case-by-case basis and more of a checklist. > >> > > > > Sounds like we need an RFC to make it clearer how voting karma for the > > RFC process will be granted in the future. > > I have created a draft for an RFC to implement future rules for granting > voting karma. > > If you want to contribute to that, feel free to open a PR against it[1]. > > To be able to make the future karma grants more trnasparent this needs > input from everyone: Opponoents as well as proponents! > > I'm looking forward to a fruitful conversation and to a great RFC that > can move us to more transparency. > > Cheers > > Andreas > > [1] > > https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas | > +---------------------------------------------------------------------+ > > As someone who only subscribed to internals a week ago, I hope you take my feedback with a grain of salt Andreas, but as this discussion has showed, this is the part of the process that my input might be valuable in. > The requester should search a proponent of their case that then proposes the request for voting karma to the dedicated discussion medium for such requests. The proposal should include the reasons why the proponent thinks the requester fullfills the above stated requirements. This makes sense for a variety of reasons. The first and most concrete being that *verifying* the credentials and history of every person who applies for karma could be restrictively time consuming if it were done in a totally open format. However, my first thought on reading this was "if I was still just an observer in internals and asking for voting karma, I would feel a little strange about emailing someone off the list directly *and* about figuring out who to message that way". Perhaps this could be paired with like... not a mentor program, but sort of a list of people on the list who are willing to field such requests? > After this request there will be a two week period in which objections and approvals will be brought in. When there are more approvals than objections the voting karma will be granted. This should be clarified. I think you intended something to the effect of " After this request there will be a two week period in which objections and approvals will be brought in. Once this period is over, if there are more approvals than objections the voting karma will be granted." The original phrasing makes it ambiguous as to whether or not the entire two weeks must pass for every such case, and also seems to suggest that someone could be granted karma with a vote of 1-0, since there would be more approvals than objections. --- Another aspect that I thought about after reading your draft was a way to structurally avoid concerns about stacking. I don't believe that there would necessarily be overt efforts to grant karma to individuals to push certain concerns to the side, however it might be worth considering if the process could promote a variety of opinions and backgrounds. Even if such a situation were considered unlikely, it could be worth writing such a process with that in mind if the process involves a sponsor. As I said earlier, it makes sense for many reasons to require a sponsor to get voting karma, however this may unnecessarily make the applicant associated with their sponsor or their sponsor's history and contributions (which could be a positive or negative to one person or the other). It also makes it less likely that a perspective which is totally unrepresented gets sponsored. This could also be a positive thing, as not all perspectives are truly relevant or constructive to all the processes. But it might be worth considering these impacts explicitly. It's also worth considering if people believe that this is a process that will be iterated on or if there is a desire to get it right the first time and stick with it. Perhaps if the intent is to iterate, or at least explicitly revisit the criteria, the RFC could include an expiration at which time a vote to either keep or change the process could be held, which gives everyone clarity and certainty about the structure over a given period. Those are my immediate thoughts on your rough draft. Jordan
