[PHP-DEV] voting without vcs accounts

Hi,

I sent an email last year about this issue, but it got sidetracked (partly
it was my fault):
http://www.mail-archive.com/[email protected]/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

On Mon, Apr 16, 2012 at 4:14 AM, Ferenc Kovacs <[email protected]> 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/[email protected]/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

Hi!

> So this time, I would like focusing only on the following:

I think before going into these, it is important to answer this
question: what is the problem we're trying to solve?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Apr 16, 2012 at 1:23 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > So this time, I would like focusing only on the following:
>
> I think before going into these, it is important to answer this
> question: what is the problem we're trying to solve?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I reject the premise of that question because it implies that nothing in
PHP should ever be changed unless it's "fixing" something that's broken.
By that standard, it would be virtually impossible to get any new features
added.

With that in mind, here's the short answer: The problem is that there is a
feature people are requesting that currently does not exist.

The longer answer: This is not a bugfix, nor does it purport to be. This
is a requested new feature proposed for the next *major* PHP release (i.e.
6.0). This feature will add convenience and allow developers o flexibly
assert more control over their code structure.

--Kris

On Mon, Apr 16, 2012 at 10:57 PM, Kris Craig <[email protected]> wrote:
> I reject the premise of that question because it implies that nothing in
> PHP should ever be changed unless it's "fixing" something that's broken.
> By that standard, it would be virtually impossible to get any new features
> added.
>
> With that in mind, here's the short answer:  The problem is that there is a
> feature people are requesting that currently does not exist.
>
> The longer answer:  This is not a bugfix, nor does it purport to be.  This
> is a requested new feature proposed for the next *major* PHP release (i.e..
> 6.0).  This feature will add convenience and allow developers o flexibly
> assert more control over their code structure.
I think you mixed up two threads here :) This one is about voting ;)

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Apr 16, 2012 at 2:00 PM, Nikita Popov <[email protected]>wrote:

> On Mon, Apr 16, 2012 at 10:57 PM, Kris Craig <[email protected]> wrote:
> > I reject the premise of that question because it implies that nothing in
> > PHP should ever be changed unless it's "fixing" something that's broken.
> > By that standard, it would be virtually impossible to get any new
> features
> > added.
> >
> > With that in mind, here's the short answer: The problem is that there
> is a
> > feature people are requesting that currently does not exist.
> >
> > The longer answer: This is not a bugfix, nor does it purport to be.
> This
> > is a requested new feature proposed for the next *major* PHP release
> (i.e.
> > 6.0). This feature will add convenience and allow developers o flexibly
> > assert more control over their code structure.
> I think you mixed up two threads here :) This one is about voting ;)
>
> Nikita
>

Oh, crap! You're right. Sorry, NM on that last post, everyone.

I hate Mondays.... :/

--Kris

On Mon, Apr 16, 2012 at 10:23 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > So this time, I would like focusing only on the following:
>
> I think before going into these, it is important to answer this
> question: what is the problem we're trying to solve?
>
>
the voting RFC explicitly states that it is possible for (some) non-vcs
users to vote, but there isn't any formal process on how can someone apply
for voting karma, and what is the decision making process on this.
we already had at least one formal submission (
http://www.mail-archive.com/[email protected]/msg54229.html) which
went unanswered and I was also questioned on irc/twitter multiple times
about how can somebody request voting karma.
I would like to be able point people to the right direction about this kind
of questions, but currently there is no official way of doing this.
I know that some of the wiki admins are already handed out a few people
voting karma, but there is no formal process, and it isn't transparent in
any way.
I would like to see that fixed.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> the voting RFC explicitly states that it is possible for (some) non-vcs
> users to vote, but there isn't any formal process on how can someone
> apply for voting karma, and what is the decision making process on this.

And what is the problem in not having the formal process?

> which went unanswered and I was also questioned on irc/twitter multiple
> times about how can somebody request voting karma.

I'd say if you have to request it and you have to ask about it on
twitter, you probably do not know enough about PHP development process
to have a deciding vote on PHP features. For non-deciding votes, we have
community voting where pretty much anyone can vote.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Apr 17, 2012 at 1:32 AM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > the voting RFC explicitly states that it is possible for (some) non-vcs
> > users to vote, but there isn't any formal process on how can someone
> > apply for voting karma, and what is the decision making process on this..
>
> And what is the problem in not having the formal process?
>

uhm. do I really have to explain it? for you? the same reason why we have
the rfc process, the release process, the voting process.
I'm not talking about 100% complete, unchangeable rules, but some kind of
process to follow.
mentioning the option for non-vcs users to vote in the voting RFC without
providing them a way to apply for karma is the same as we wouldn't mention
it at all.
I could also accept if we don't allow them, but then we should be clear
about it.


>
> > which went unanswered and I was also questioned on irc/twitter multiple
> > times about how can somebody request voting karma.
>
> I'd say if you have to request it and you have to ask about it on
> twitter, you probably do not know enough about PHP development process
> to have a deciding vote on PHP features.


no, it only means that our internal processes aren't clear or easily
accessible.
people outside the circle can't do much, than asking people inside to let
them in.


> For non-deciding votes, we have
> community voting where pretty much anyone can vote.
>

you mean the +1/-1 on the mailing list threads?
that's nice, but I'm talking about the voting laid out in the voting
process rfc https://wiki.php.net/rfc/voting (what you also supported).

as I mentioned before, I can live with it if we remove the ability for
non-vcs users to vote, but in that case we should update the rfc (and the
karma check in the wiki) accordingly.
but if we decide to keep it, we should make it possible for people to be
able to request for voting karma, and a way to handle those requests.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> no, it only means that our internal processes aren't clear or easily
> accessible.
> people outside the circle can't do much, than asking people inside to
> let them in.

If somebody is an outsider to PHP development, why do you think giving
him a deciding vote on it would be a good thing? One can discuss things,
propose changes, etc. without any special access.

> you mean the +1/-1 on the mailing list threads?

No, I mean community voting in the wiki. Voting plugin has option to
allow anybody to vote. We did such polls in the past. We can do it any day.

> but if we decide to keep it, we should make it possible for people to be
> able to request for voting karma, and a way to handle those requests.

Why sending a message to the list is not enough?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Apr 17, 2012 at 1:58 AM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > no, it only means that our internal processes aren't clear or easily
> > accessible.
> > people outside the circle can't do much, than asking people inside to
> > let them in.
>
> If somebody is an outsider to PHP development, why do you think giving
> him a deciding vote on it would be a good thing? One can discuss things,
> propose changes, etc. without any special access.
>

thats something which the current voting RFC allows. it seems that we are
already over on that decision, as the accepted RFC had that clause.


>
> > you mean the +1/-1 on the mailing list threads?
>
> No, I mean community voting in the wiki. Voting plugin has option to
> allow anybody to vote. We did such polls in the past. We can do it any day.
>

I'm not sure about it. AFAIK when I implemented my patch to restrict the
voting to the vcs users + the voting wiki group, we lost that ability. (see
http://www.mail-archive.com/[email protected]/msg51932.html for the
history of that change)


>
> > but if we decide to keep it, we should make it possible for people to be
> > able to request for voting karma, and a way to handle those requests.
>
> Why sending a message to the list is not enough?
>

dunno, but it seems it isn't, as nobody replied or gave voting karma to
William.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> I'm not sure about it. AFAIK when I implemented my patch to restrict the
> voting to the vcs users + the voting wiki group, we lost that ability.
> (see http://www.mail-archive.com/[email protected]/msg51932.html for
> the history of that change)

I don't see any indication there that community vote is not possible,
but if it was changed we can make community vote be available again.

My point is that we are talking about some formal processes but I don't
see what would be the desired purpose of such processes. For release
process, it's releasing a stable code in time. For RFC, it is informing
people about proposed feature and getting it discussed and hopefully
accepted. Here, I'm not sure what is the goal.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Apr 17, 2012 at 2:28 AM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > I'm not sure about it. AFAIK when I implemented my patch to restrict the
> > voting to the vcs users + the voting wiki group, we lost that ability.
> > (see http://www.mail-archive.com/[email protected]/msg51932.htmlfor
> > the history of that change)
>
> I don't see any indication there that community vote is not possible,
> but if it was changed we can make community vote be available again.
>
>
http://www.mail-archive.com/[email protected]/msg51948.html
Pierre said that it was a bug(better to say lack of restriction), that
everybody with wiki account was able to vote, so I changed the voting
plugin to only allow the specific groups(vcs + voting) to be able to vote.
nobody asked that we would still need to keep the ability to create "open"
votes where anybody can vote, so it wasn't implemented.


> My point is that we are talking about some formal processes but I don't
> see what would be the desired purpose of such processes. For release
> process, it's releasing a stable code in time. For RFC, it is informing
> people about proposed feature and getting it discussed and hopefully
> accepted. Here, I'm not sure what is the goal.
>

To be able to get voting karma if you meet the requirements. without the
need to bribe Hannes, Philip or any other wiki admin.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Mon, Apr 16, 2012 at 4:58 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > no, it only means that our internal processes aren't clear or easily
> > accessible.
> > people outside the circle can't do much, than asking people inside to
> > let them in.
>
> If somebody is an outsider to PHP development, why do you think giving
> him a deciding vote on it would be a good thing? One can discuss things,
> propose changes, etc. without any special access.
>

Just to play devil's advocate (Satan and I go way back), what about people
who are established PHP developers but who generally don't participate in
the development/discussion of PHP core? An argument could be made that, as
the users of PHP, they should be able to have some say in its development.
That's not my position, mind you; I'm just throwing that premise out there
to see if it holds up. =)

>
> > you mean the +1/-1 on the mailing list threads?
>
> No, I mean community voting in the wiki. Voting plugin has option to
> allow anybody to vote. We did such polls in the past. We can do it any day.
>
> > but if we decide to keep it, we should make it possible for people to be
> > able to request for voting karma, and a way to handle those requests.
>
> Why sending a message to the list is not enough?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

>
>
> Just to play devil's advocate (Satan and I go way back), what about people
> who are established PHP developers but who generally don't participate in
> the development/discussion of PHP core? An argument could be made that, as
> the users of PHP, they should be able to have some say in its development..
> That's not my position, mind you; I'm just throwing that premise out there
> to see if it holds up. =)
>

could you please open a separate thread for that?
btw. "regular participant of internals discussions" is one of the reason on
which group someone can get voting karma.
so if that is provided, anybody have a chance to get join
the decision making process.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs <[email protected]> wrote:

>
>> Just to play devil's advocate (Satan and I go way back), what about
>> people who are established PHP developers but who generally don't
>> participate in the development/discussion of PHP core? An argument could
>> be made that, as the users of PHP, they should be able to have some say in
>> its development. That's not my position, mind you; I'm just throwing that
>> premise out there to see if it holds up. =)
>>
>
> could you please open a separate thread for that?
> btw. "regular participant of internals discussions" is one of the reason
> on which group someone can get voting karma.
> so if that is provided, anybody have a chance to get join
> the decision making process.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Why would that be a separate thread? Isn't that what we're talking about?
I.e. determining who gets voting access and who doesn't?

--Kris

On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig <[email protected]> wrote:

>
>
> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs <[email protected]> wrote:
>
>>
>>> Just to play devil's advocate (Satan and I go way back), what about
>>> people who are established PHP developers but who generally don't
>>> participate in the development/discussion of PHP core? An argument could
>>> be made that, as the users of PHP, they should be able to have some say in
>>> its development. That's not my position, mind you; I'm just throwing that
>>> premise out there to see if it holds up. =)
>>>
>>
>> could you please open a separate thread for that?
>> btw. "regular participant of internals discussions" is one of the reason
>> on which group someone can get voting karma.
>> so if that is provided, anybody have a chance to get join
>> the decision making process.
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>>
>
> Why would that be a separate thread? Isn't that what we're talking
> about? I.e. determining who gets voting access and who doesn't?


I just ask for clarification on how the community representatives (which is
defined in the accepted voting RFC) can get their karma.
You are talking about changing the requirements for somebody to be able to
participate in the voting, thus changing/extending the original RFC.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Mon, Apr 16, 2012 at 6:21 PM, Ferenc Kovacs <[email protected]> wrote:

>
>
> On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig <[email protected]> wrote:
>
>>
>>
>> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs <[email protected]> wrote:
>>
>>>
>>>> Just to play devil's advocate (Satan and I go way back), what about
>>>> people who are established PHP developers but who generally don't
>>>> participate in the development/discussion of PHP core? An argument could
>>>> be made that, as the users of PHP, they should be able to have some say in
>>>> its development. That's not my position, mind you; I'm just throwing that
>>>> premise out there to see if it holds up. =)
>>>>
>>>
>>> could you please open a separate thread for that?
>>> btw. "regular participant of internals discussions" is one of the reason
>>> on which group someone can get voting karma.
>>> so if that is provided, anybody have a chance to get join
>>> the decision making process.
>>>
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>>>
>>
>> Why would that be a separate thread? Isn't that what we're talking
>> about? I.e. determining who gets voting access and who doesn't?
>
>
> I just ask for clarification on how the community representatives (which
> is defined in the accepted voting RFC) can get their karma.
> You are talking about changing the requirements for somebody to be able to
> participate in the voting, thus changing/extending the original RFC.
>

It's the same topic, and the question of who *should* or should not be
allowed to vote was already raised previously on this thread. That's what
I was responding to. So, deep breath.... =)

--Kris


> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Kris Craig wrote:
> An argument could be made that, as the users of PHP, they should be
> able to have some say in its development.

As a PHP developer (that is, a developer who writes in PHP), I'd agree,
*to an extent*. There are certainly things that I'd like to be able to
vote on (such as additions to the language/syntax and things such as
..phpp). However, I've got no idea how easy such things are to implement,
so I don't feel qualified to even ask to be able to vote.

However, these things are going to influence me as a developer, so I'd
like to be able to vote.

Take, as an example, the .phpp debates. (Just as an example.) If I
didn't like it, I'd like to be able to vote against it to avoid having
to handle it later. However, if I *was* for it, I wouldn't feel
qualified to comment, as I have no idea how hard these things are to
implement.

(Just my $0.02. Apologies if this is confusing, I'm a mixture of tired
and distracted.)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Apr 16, 2012 at 7:41 PM, Ryan McCue <[email protected]> wrote:

> Kris Craig wrote:
>
>> An argument could be made that, as the users of PHP, they should be able
>> to have some say in its development.
>>
>
> As a PHP developer (that is, a developer who writes in PHP), I'd agree,
> *to an extent*. There are certainly things that I'd like to be able to vote
> on (such as additions to the language/syntax and things such as .phpp).
> However, I've got no idea how easy such things are to implement, so I don't
> feel qualified to even ask to be able to vote.
>
> However, these things are going to influence me as a developer, so I'd
> like to be able to vote.
>
> Take, as an example, the .phpp debates. (Just as an example.) If I didn't
> like it, I'd like to be able to vote against it to avoid having to handle
> it later. However, if I *was* for it, I wouldn't feel qualified to comment,
> as I have no idea how hard these things are to implement.
>
> (Just my $0.02. Apologies if this is confusing, I'm a mixture of tired and
> distracted.)
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hmm yeah that makes sense. What if we split the questions into multiple
parts? For example, the first question would be something along the lines
of, "Conceptually, do you think this is a good idea?" That could be open
to PHP developers as well. Then the second question could be, "If you
answered 'Yes', as a core contributor, do you believe this proposal is
technically feasible?" That question would be open only to the people who
can vote now.

Mind you, I'm just throwing this out there off the top of my head. It
could be a really stupid idea, but I thought it might provoke some
interesting discussion at the very least. With that in mind.... Thoughts?
=)

--Kris

On Apr 16, 2012, at 6:21 PM, Ferenc Kovacs wrote:

> On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig <[email protected]> wrote:
>
>>
>>
>> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs <[email protected]> wrote:
>>
>>>
>>>> Just to play devil's advocate (Satan and I go way back), what about
>>>> people who are established PHP developers but who generally don't
>>>> participate in the development/discussion of PHP core? An argument could
>>>> be made that, as the users of PHP, they should be able to have some say in
>>>> its development. That's not my position, mind you; I'm just throwing that
>>>> premise out there to see if it holds up. =)
>>>>
>>>
>>> could you please open a separate thread for that?
>>> btw. "regular participant of internals discussions" is one of the reason
>>> on which group someone can get voting karma.
>>> so if that is provided, anybody have a chance to get join
>>> the decision making process.
>>>
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>>>
>>
>> Why would that be a separate thread? Isn't that what we're talking
>> about? I.e. determining who gets voting access and who doesn't?
>
>
> I just ask for clarification on how the community representatives (which is
> defined in the accepted voting RFC) can get their karma.
> You are talking about changing the requirements for somebody to be able to
> participate in the voting, thus changing/extending the original RFC.

The voting RFC is unclear but aside from that, there are two non-vcs
accounts with voting karma today:

User: damz: Damien Tournoud - damz@damz.org
User: hywan: Ivan Enderlin - ivan.enderlin@hoa-project.net

Not saying they should or should not, but just saying. And I'm not sure
how/when they received the voting karma but it happened.

Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
>
>>> Why would that be a separate thread? Isn't that what we're talking
>>> about? I.e. determining who gets voting access and who doesn't?
>>
>>
>> I just ask for clarification on how the community representatives (which
>> is defined in the accepted voting RFC) can get their karma.
>> You are talking about changing the requirements for somebody to be able
>> to participate in the voting, thus changing/extending the original RFC.
>>
>
> It's the same topic, and the question of who *should* or should not be
> allowed to vote was already raised previously on this thread. That's what
> I was responding to. So, deep breath.... =)
>
>
I think Stas was a little bit offtopic/red herring with the discussion on
why do we need non-vcs people to be allowed to vote.
But to use that as an excuse to hijack the thread to resurrect the "why
can't everybody vote" discussion isn't really nice, and I even asked it
especially to not to do, as that was the reason which halted my previous
attempt to address this issue.
Could we all please focus on the original topic?
Thanks!

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> http://www.mail-archive.com/[email protected]/msg51948.html
> Pierre said that it was a bug(better to say lack of restriction), that
> everybody with wiki account was able to vote, so I changed the voting
> plugin to only allow the specific groups(vcs + voting) to be able to vote.

This is the authenticated vote. It has also option of having
non-authenticated vote.

> My point is that we are talking about some formal processes but I don't
> see what would be the desired purpose of such processes. For release
> process, it's releasing a stable code in time. For RFC, it is informing
> people about proposed feature and getting it discussed and hopefully
> accepted. Here, I'm not sure what is the goal.
>
>
> To be able to get voting karma if you meet the requirements. without the
> need to bribe Hannes, Philip or any other wiki admin.

I don't see how getting you "voting carma", whatever it might be, can be
a goal of PHP project. I'm talking about the goal of the whole thing.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Apr 17, 2012 at 11:48 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > http://www.mail-archive.com/[email protected]/msg51948.html
> > Pierre said that it was a bug(better to say lack of restriction), that
> > everybody with wiki account was able to vote, so I changed the voting
> > plugin to only allow the specific groups(vcs + voting) to be able to
> vote.
>
> This is the authenticated vote. It has also option of having
> non-authenticated vote.
>

ok, I didn't knew/remembered that.

> To be able to get voting karma if you meet the requirements. without the
> > need to bribe Hannes, Philip or any other wiki admin.
>
> I don't see how getting you "voting carma", whatever it might be, can be
> a goal of PHP project. I'm talking about the goal of the whole thing.
>
>
sorry, I can't really follow you with that.
do you have a problem allowing the non-vcs users (defined by the voting
rfc) to vote, or do you have a problem providing a clear way for them to
get their voting karma?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> sorry, I can't really follow you with that.
> do you have a problem allowing the non-vcs users (defined by the voting
> rfc) to vote, or do you have a problem providing a clear way for them to
> get their voting karma?

I have a problem that we don't have understanding of what is the goal of
this whole vote setup. What is it for? What we will be doing with it?
And please don't say "it says so in RFC" - it is not a goal.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 04/17/2012 03:50 PM, Stas Malyshev wrote:
> Hi!
>
>> sorry, I can't really follow you with that.
>> do you have a problem allowing the non-vcs users (defined by the voting
>> rfc) to vote, or do you have a problem providing a clear way for them to
>> get their voting karma?
>
> I have a problem that we don't have understanding of what is the goal of
> this whole vote setup. What is it for? What we will be doing with it?
> And please don't say "it says so in RFC" - it is not a goal.

Stas, I'm with Ferenc on this. We just need one or two sentences somewhere
in the wiki saying how non-contributors can get vote karma. The sentences
should give the physical process and what kind of people we will give karma to.

Chris

--
christopher.jones@oracle.com
http://twitter.com/#!/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Apr 17, 2012, at 4:08 PM, Christopher Jones wrote:

>
>
> On 04/17/2012 03:50 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> sorry, I can't really follow you with that.
>>> do you have a problem allowing the non-vcs users (defined by the voting
>>> rfc) to vote, or do you have a problem providing a clear way for them to
>>> get their voting karma?
>>
>> I have a problem that we don't have understanding of what is the goal of
>> this whole vote setup. What is it for? What we will be doing with it?
>> And please don't say "it says so in RFC" - it is not a goal.
>
> Stas, I'm with Ferenc on this. We just need one or two sentences somewhere
> in the wiki saying how non-contributors can get vote karma. The sentences
> should give the physical process and what kind of people we will give karma to.

The problem is that the voting RFC does not define who can vote. It contains
two parts:

1. Those with SVN [sic] access (but how does karma come into play?)
2. Those without (how do we provide such rights? to whom?)

If these are to be answered (they should) then I don't think an RFC can be
edited like that (people already voted on it), so suspect we'd need a new
RFC to replace it. Fun!

I suspect most people voted "Yes" for that RFC thinking it'd mean less noise
on this list while not caring about the details. That's only a guess. But
trouble is, defining the "Who" is the most difficult part and a big reason why
general consensus is preferred.

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi Stas,

On Wed, Apr 18, 2012 at 12:50 AM, Stas Malyshev <[email protected]> wrote:

> I have a problem that we don't have understanding of what is the goal of
> this whole vote setup. What is it for? What we will be doing with it?
> And please don't say "it says so in RFC" - it is not a goal.

Let me clarify that and try to do not go backwards while we have
finally moved forward.

The goal is to have community leader participating in our design
discussions and decisions. It has happened already for a couple of
RFCs (accepted and rejected) and went very well. The FUDs about core
devs, legacy developers and the like loosing control about the
direction PHP takes has been killed, it did not happen and it is very
unlikely that it will happen.

How do the community leaders come in? They are usually very well known
and already participate to php in one way or another (bugs report,
testing, etc.) and are part of a known OSS project (we have drupal,
zf, symfony already for example). Having a couple of devs to second
their addition is also requested.

This has been said many times already in the past and it is said in
the RFC as well. We do not need over killed process as an attempt to
make php more closed to our communities.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson <[email protected]> wrote:

>  1. Those with SVN [sic] access (but how does karma come into play?)

It does, or we begin to have 2nd, 3rd and totally irrelevant classes
of developers or doc writers.

>  2. Those without (how do we provide such rights? to whom?)

See my other reply, easy, simple, harmless.

> I suspect most people voted "Yes" for that RFC thinking it'd mean less noise
> on this list while not caring about the details. That's only a guess. But
> trouble is, defining the "Who" is the most difficult part and a big reason why
> general consensus is preferred.

I prefer not to comment on that part. It is like saying that people
are not able to take a qualified decision, for whatever reasons. I
have been myself tempted to think or say the same about some of the
php.net members, and have been proven wrong many times. So let ignore
this comment.


Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Apr 18, 2012 at 7:37 AM, Pierre Joye <[email protected]> wrote:
> hi,
>
> On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson <[email protected]> wrote:
>
>>  1. Those with SVN [sic] access (but how does karma come into play?)
>
> It does, or we begin to have 2nd, 3rd and totally irrelevant classes
> of developers or doc writers.

A "not" was missing. It should have been:

It does not, or we begin to have 2nd, 3rd and totally irrelevant
classes of developers or doc writers.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php