Hey Mike Thank you for your feedback!
Am 20.07.21 um 11:57 schrieb Mike Schinkel: > Quoting the RFC > >> the requester has contributed to the PHP sourcecode ecosystem. > > You mention what types of contributions apply, but give no indication of > quantity. If someone fixes one bug, does that give them voting rights? I > would assume not. So is it two bugs, 10 bugs, 100? As the RFC is still not finished especially in terms of wording that is something that definitely needs some improvements. I tried to leave it as open as possible in the initial draft to have that as basis for further discussions. What do you think would be an appropriate number? > >> these contributions show a consistent effort > > How is "consistent" defined? How frequently and for what minimum time period? This is the same "blurriness" as above due to the same reasons. Any suggestions for a better wording? For me consistent means that someone keeps at something for the duration of that process. So not like giving a comment to a bug report and off but instead continuously monitoring the bug, answering comments, triaging the bug, looking to find someone to fix it, writing tests for it etc. But yes, that is not described in the RFC and that'S just my personal take. Being explicit definitely is better there. Though perhaps we should not become too explicit and still allow a certain amount of interpretation. > >> the requester has shown interaction with the main discussion medium of the >> relevant part > > > This is unclear to me. I assume "the main discussion medium" is more than > just the mailing list, otherwise you would have said the mailing list, right? The "main discussion medium" is currently the Mailinglist. As I have no idea of when this RFC will be ready for voting I kept it that vague to not have to rewrite everything should for whatever reason the mailing list be replaced with something else. For some things the mailing-list has already been replaced with the PR-Comments > > And what does "relevant part" mean? Maybe some examples would help, at > least in reply. See above ;-) > >> the requester has a proponent that currently has voting karma > > Agreeing with Jordan LeDoux, these seems primed to make current voting > members a target for wanna-be voters. > > Maybe this could discuss processes that would naturally bring people to want > to sponsor someone, such as (maybe?) recommending they first "apprentice" > under one or more people by helping document, helping fix bugs, or working > with them on an RFC? My main idea was to limit the number of emails to the mailinglist by requesting them to come from someone already with voting karma so that there is a slight barrier of entrance. And during the preparation process for the voting karma someone would hopefully not work in an empty space but have contacts to other people with voting karma. So that they can guide the person through the process. And as the process requires someone to have interacted with the system beforehand that should not lead to too many wanna-be voters out of the blue > >> 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. > > Are you really suggesting that allowing someone new to vote would be held out > in the open, where the discussions about that person will get recorded on > externals.io <http://externals.io/> and indexed by Google for all to see, > forevermore? > > Seems like discussion about an individual should respect the long term > privacy of the individual a bit more, especially for those who will be turned > down. Thanks! I actually hadn't thought about that! Any suggestions on how to improve that? > >> When there are more approvals than objections the voting karma will be >> granted. > > How is voting to be done? Yay's and nay's on a mailing list? Or some other > way? Someone else suggested to have a similar voting widget like we have for the RFCs as that would ease the whole thing considerably. I'll add that suggestion to the Draft. > > And voting right can be approved with 51% whereas most RFCs require 67% to > pass? Only RFCs that change the language need 2/3rd majority. ANd the RFC we are talking here would need that. But you are right. When the poll is that close that means there are a lot of objections against that person (whyever) so we might think about that. On the other hand that would mean that we might miss valuable input from people that contribute to the PHP-System... > > I ask these questions so people who might be interested in getting voting > rights would have an objective roadmap for how to get there otherwise it > would seem to just be documenting an extremely subjective process. (Which > might be all you are attempting to do?) I'm trying to create exactly that: An objective roadmap what to do to get voting rights. What I did not yet get into is the question what to do when someone did a lot of effort to get voting rights and right after that stops all efforts. Perhaps we should add a passage to the RFC regarding that as well. Thanks though for your input! Cheers Andreas -- ,,, (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 | +---------------------------------------------------------------------+
OpenPGP_signature
Description: OpenPGP digital signature
