On Tue, Jul 20, 2021 at 2:22 AM 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 > Here is the problem (and I don't know if there is a good solution to this) - the requirements are still subjective. How much interaction is required with the PHP sourcecode ecosystem? What is considered a "consistent effort?" How much interaction with the "main discussions medium" is needed? If we are going to change how karma is given, I think we really need to determine solid, objective criteria. I honestly don't know what this looks like. Everything I can think of has issues. For example, if we decided to allow a path for non-core contributors to gain karma, what would we base that on? Anything around the number of commits, projects worked on, etc., can be easily gamed. Allowing those that already have voting karma the final decision over who gets voting karma is also problematic. Like Tobias, I have gotten the "elitist" feeling at times from the group. Finally, I think the idea of "approvals outweighing objections" is not good. While it definitely is a purely objective measurement, it shows why I think it is so hard (if not impossible) to find good measurements that are purely objective. What if we get one objection that rightly says "This person shows that they have no knowledge of how PHP actually works" compared to two approvals saying "I like this person, so I'm OK with it" -- Chase Peeler chasepee...@gmail.com
