On Mon, Apr 16, 2012 at 4:14 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > Hi, > > I sent an email last year about this issue, but it got sidetracked (partly > it was my fault): > http://www.mail-archive.com/internals@lists.php.net/msg54267.html > So this time, I would like focusing only on the following: > > 1. What are the requirements for getting voting rights in the wiki > without having a vcs/master account? > - The voting RFC states: > - Representatives from the PHP community, that will be chosen by > those with php.net SVN accounts > - Lead developers of PHP based projects (frameworks, cms, > tools, etc.) > - regular participant of internals discussions > 2. What are the necessary steps from a volunteer to request voting > karma? > 3. How do we handle the applicants? Who will "judge" the applications? > 4. How can we see the list of the people having voting karma? Currently > only the wiki admins can see who are the people with the voting group > membership. > > > The wiki is already prepared to support voting without vcs account: there > is a voting group, anybody having membership in that group are able to vote > ( > http://git.php.net/?p=web/wiki.git;a=commit;h=e3b97f03548fab661b5bc2dd66420db1024b1f39 > ). > > My personal opinion would be that we have an application form like we have > for the vcs account request, which will send an email to the mailing list, > we can discuss here whether we support/approve the applicant or not, and > somebody with proper karma can approve/decline the application, which would > also trigger an email to the mailing list. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu
I'm completely in favor of a formal process since it would mean there can be less biased and favor applied to the selection and this can eliminate the potential for people being included to vote for or against something for the purpose of overtaking the vote. I think PHP is already a very inclusive environment. Given that php.net now has edit.php.net and has streamlined the process of submitting bug reports both for documentation and language bugs I think the inclusion into the voting process as a formal outline and drafted step-by-step process will further help put PHP in a position of higher power among its neighboring communities. I propose three primary suggestions for helping formulate such a process: 1) The person requesting voting privileges in the RFC voting process should have either (a) contributed to the PHP community in a constructive and contemporary manner such as submitting helpful bug reports for docs or language bugs (did not contribute noise or repeat bugs or lack of reproducible test cases in the recent past), (b) participates in submitting patches to the PHP source repository, (c) participates in actively in php.net or wiki.php.net without a known history of disruptions among the community. 2) The person requesting voting privileges should only be allowed to make the request once every so often (such as on a monthly or quarterly, or even annual basis, for example). This will help avoid constant requests that just get turned down and avoid a load on applicants. Also, the applicant should be reviewed by their peers as well as the SVN account holders to avoid prejudice. If this is not possible it should at least be set in some fashion what guidelines/prerequisites would appeal to the potential applicant so that people can have a set expectation of what to look for before approaching such privileges. 3) Anyone who is not included in the voting process should not be turned down or discouraged from trying again (after an allotted waiting period) so as to keep the voting process lean and fair. However, I think it may also be fair to request that those re-sending a request to gain voting privileges should be required to produce some supporting evidence for their active and positive roles in their community, such as previous patches, bug report ids, mailing list archives discussions demonstrating some constructive feedback, logs, etc... I'm sure more can be made of this list in time. I just thought to start the discussion off with some constructive suggestions. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
