Skip to main content

[VOTE] Voting Procedures

13 replies [Last post]
rbair
Offline
Joined: 2003-07-08
Points: 0

I'm proposing that we use the Apache Foundations voting guidelines as our official rules with respect to voting. They can be found here (http://www.apache.org/foundation/voting.html).

In addition to these rules, I'm proposing that all votes be on their own thread, and be prefixed by "[VOTE]", followed by a description of what the vote is for. In addition, unless otherwise specified, votes are open for 3 days and follow the same rules as specified in the above doc.

Also, only committers on the specific projects being voted on are considered to have "binding" votes. So, if the issue being voted on is for the incubator, then everybody with developer access to the incubator may cast binding votes. The same goes for SwingX, DataBinding, etc. Everyone else is welcome to cast a vote, but they are non-binding votes.

+1 from me :)

The results of this vote will be written up and posted on the swinglabs.dev.java.net website for future reference.

Richard

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rbair
Offline
Joined: 2003-07-08
Points: 0

> - do we have a sense of what requires a vote, and
> what doesn't? In
> Apache, this is important because "code modification"
> can be vetoed by
> a single committer.

One thing we want to avoid is a heavy-handed approach. In general (especially in SwingX), people have certain areas of responsiblity and we want to avoid messing around in each other's areas without permission. In cases where, for example, you and I are both working in the same space (DataSet), it is good for us to communicate together, but that doesn't [i]necessarily[/i] require a vote.

In my mind, voting is something that is manditory for code changes that are either 1) controversial (common sense should dictate here), or 2) cross-cutting (like fixing imports, logging statements, etc). Voting is also a good choice when code modifications are large and you want to get feedback from the community.

However, any change that is being made (or has been made) in any area of the code base can be brought into question for a vote by *any* committer in the project. For example, if DevX makes certain changes to the JXTreeTable that DevY finds appalling, DevY should be able to call the change into question. Of course, according to the rules, DevY must have technical grounds for the vote, not simply asthetics or taste.

Its possible for this definition to be abused, though I highly doubt that will be the case. I expect that this rule definition will allow reasonable grounds for voting, and I find the committers on these projects to be quite reasonable people.

> - should all CVS committers on a given SwingLabs
> subproject have equal
> weight in voting (see my original reply for more
> details).

Yes. I don't expect that people will abuse this right.

Richard

Patrick Wright

I think then that API proposals don't need to be voted on but should
be discussed, and we've been good about that. The exception would be
API changes that affect developers already using the current API,
where that's been stable for awhile.

It seems this is what we're already doing, so, after thrashing it out
with you all then, I withdraw any reservations.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Ann Sunhachawee

+1

Though not sure if i missed if there are any guidelines as to stating
when the vote will conclude (although the min. of 72 hours is there)

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

This seems alright

+1

but some things need more discussion:

- when asking for a vote, need to make clear what sub-project it is for
[Vote]: DataBinding - DataSet - {issue}

- need to clarify what code modifications are worthy of a vote, and
which aren't. we need to allow for a certain amount of flexibility in
working on code--so are we voting on public APIs, internal design,
overall design, what? "code modification" in the apache system isn't
well defined. some possible categories (off the top of my head)
- public APIs - method names, method semantics, class composition
- protected (and thus overridable) APIs
- "general design"

"general design" might be something like: DataViews are implemented as
Decorators around a DataTable, as subclasses vs. DataViews are
implemented as Decorators around a Pipeline

- need to be careful not to vote on too many topics in one thread (a
whole set of changes proposed at once that are only related because
they affect the same components)

- the java.net membership system might not be constrained enough to
capture "participation" for voting. for example, I have commit access
to swingx, but apart from proposing a status bar design, and
submitting some javadocs, i'm really not familiar with the intimate
issues relating to swing gui component development. so probably i
shouldn't have a binding vote on swingx topics. what we might do
instead is have an "owner" for different sub-projects (and there might
be more than one sub-project in a java.net sub-project), and binding
votes go to people that owner decides belong on the list, who at a
minimum have commit access, and that list would be posted (we could
vote on who belongs to that list? it will be contentious, probably,
but either way the process should be transparent). that may be harsh,
but it would be unfair for someone to block votes who wasn't really in
the trenches with the code. i have opinions about highlighters, but
that doesn't mean i know what i'm talking about when referring to
them.

In general, I think we're feeling our way towards a process that
works, more or less. The incubator has been useful in some cases in
developing new ideas that migrate upwards, but often proposals there
just get lost in the shuffle. Our process seems to do better for items
already in the main trunk. If we had a better round-trip with the
incubator, then, say, Jeanette could mock up a new Highlighter API
there (if the API was changing significantly), then ask for
discussion, repeat until ready for a vote, a positive vote gets it
moved into the main trunk.

As long as we can clarify some of these questions, I'm in favor of the
Apache proposal.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Hi Patrick

>
> but some things need more discussion:
>

which might lead to yet another rule - first discuss an issue and
then put it to vote in a different thread?

In general, I'm opposed to overdoing it with rules, be it on voting,
procedures, code - establishing them often takes more time than they are
worth. Just as much that we - that is every member of the SwingLabs
community - feels good or can be convinced to feel reasonably
comfortable with the overall result. So I 100% agree with:

> In general, I think we're feeling our way towards a process that
> works, more or less.

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Hi Jeanette

Wonderful weather for October, huh?

> which might lead to yet another rule - first discuss an issue and
> then put it to vote in a different thread?

Yes, that would resolve most of my concerns. Mainly I think voting should be
- about one issue, or a small set of tightly related issues (where one
vote makes sense)

- should be preceeded by discussion on a separate thread (moderator
can chop discussion off at will and request a vote)

The two outstanding issues for me are,

- do we have a sense of what requires a vote, and what doesn't? In
Apache, this is important because "code modification" can be vetoed by
a single committer.

- should all CVS committers on a given SwingLabs subproject have equal
weight in voting (see my original reply for more details).

Cheers
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Hi Patrick
>
> Wonderful weather for October, huh?
>

yeah! And lucky me - I have to go out later this afternoon (demo'ing
against Charité's wage policy :-)

>
> Yes, that would resolve most of my concerns. Mainly I think voting should be
> - about one issue, or a small set of tightly related issues (where one
> vote makes sense)
>
> - should be preceeded by discussion on a separate thread (moderator
> can chop discussion off at will and request a vote)
>
>

100% ack.

> The two outstanding issues for me are,
>
> - do we have a sense of what requires a vote, and what doesn't? In
> Apache, this is important because "code modification" can be vetoed by
> a single committer.
>

We don't have any experience about voting on "code modification", until
now I never felt the need to do so. Plus the number of active developers
(those participating in any given discussion) is not very high anyway -
so a requirement to vote before doing anything looks too restrictive to
me. This may change in future, but for now we might be better off to not
require voting on code modifications at all.

Personally, I see SwingLABS - which is meant to have a strong streak of
experimentation. So instead of voting on a controversial issue, I would
prefer to allow the variation and decide later. At that later time we
might see clearer what is working or not.

> - should all CVS committers on a given SwingLabs subproject have equal
> weight in voting (see my original reply for more details).
>

In a strict sense, probably not - but currently I don't see any real
problem. We usually succeed in convincing each other. Hmm ... or letting
a controversy/open question dribble out without conclusion ... which is
not so good.

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Hi Jeanette

> We don't have any experience about voting on "code modification", until
> now I never felt the need to do so. Plus the number of active developers
> (those participating in any given discussion) is not very high anyway -
> so a requirement to vote before doing anything looks too restrictive to
> me. This may change in future, but for now we might be better off to not
> require voting on code modifications at all.
>
> Personally, I see SwingLABS - which is meant to have a strong streak of
> experimentation. So instead of voting on a controversial issue, I would
> prefer to allow the variation and decide later. At that later time we
> might see clearer what is working or not.

I think we're not on the same page here--the most important aspects
(IMO) of the Apache proposal Richard sent was that code modifications
could be veto'ed.

What I think we need to clarify is what "code modifications" means for
SwingLabs. For example, you posted a discussion on highlighters, which
included a proposal for how highlighters should interact with LnF
colors. If you went ahead with that proposal, you'd change the
out-of-the-box behavior of highlighters in a table, in a (possibly)
noticeable way. It's more or less changing the contract for the
highlighter, although the API itself might not change. My guess would
be that would be a "code modification" and something that should be
voted on.

The other case is where you have some internal plumbing you're seeking
feedback on in a discussion which doesn't affect the public contract.
I'd say that would require a vote if it would "significantly" impact
developers who extend the class, but not require a vote otherwise.

Maybe, to put it more simply: we should have vetoable votes on the
public contracts for the classes, as well as for internal
implementation that can affect end-developers "in a significant way".

Whatever we do, this thread is about voting, so the questions are:
what gets put to a vote, and what can be veto'ed, and who can veto a
proposal.

Cheers
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

nearly forgot to vote :-)

+1

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

evickroy
Offline
Joined: 2004-07-23
Points: 0

+1

> Also, only committers on the specific projects being
> voted on are considered to have "binding" votes.
So to clarify, since the VOTE didn't specify a "specific project", then I guess it applies to them all right? I just don't want the official tally to be incorrect and see Richard and Kleopatra spending nights and weekends counting and recounting chads. ;)

Erik

rturnbull
Offline
Joined: 2005-08-27
Points: 0

+0 Happy to use the procedural voting procedures to cast a nonbinding vote for the procedural voting procedures.

Have a nice day

dmouse
Offline
Joined: 2003-06-09
Points: 0

+1 Happy to have a procedure for this.

Amy Fowler

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net