Mar 13 2013
Mar 13

A week or so ago, Dries posted this

Which links to a number of draft charters for working groups focussed on different facets of the community, the software project, our tools and infrastructure.

Dries wrote

This is a work in progress. Please help shape the future of governance by reviewing and commenting on the following proposals:

Please take a moment to review Dries post, and each of the draft charters. Please comment, and please help spread the word about this proposal. It's important. :-)

Sep 24 2012
Sep 24

Voting is now open in the community elections for new Directors "At Large".

How to vote?

  1. Login to
  2. Check box and confirm you're eligible to vote.
  3. Rank the candidates in your order of preference.
    You do not need to rank all candidates.
    Why rank them? Watch this video.
  4. Save the form.

Voting is open for two weeks, closing at 23:59 UTC 7 Oct 2012.

Sep 17 2012
Sep 17

Here, in the order they submitted their nominations are the candidates for the 2013 election.

Voting is open September 24 - October 7.

Full name links to nomination statement, username links to profile on

  • (withdrawn)
Aug 31 2012
Aug 31

The time has come to open nominations for directors from the community at large for the board of the Drupal Association.

The key details are:

Election Timeline

  • Sep 1-16 Nominations open
  • Sep 17-23 Statements, Questions, Meet the Candidates sessions
  • Sep 24-Oct 7 Voting
  • Oct 10 Ratify results at board meeting

How to submit a nomination

Dec 29 2011
Dec 29

This planning document produced a plan for the 2012 Drupal Association elections of at large directors that was approved by the DA board.

The Drupal Association is holding its first round of elections for board members under its new governance structure. See the the elections announcement for background and details. To invite community input on how best to run the elections, we've outlined below some possible suggestions, along with their pros and cons. Please tell us what you think by posting comments, or add your ideas!

What aims should a voting system meet?

To clarify our best options in an election system, it may help to capture goals. What are we trying to achieve?

  • Provide a basis to evaluate the success of this initial round of elections and provide feedback and recommendations.
    Note: We are electing two community members "At Large" to sit on the board of directors of the Drupal Association. We are not voting for a governing body of Drupal. The Board does not "make law" for the Drupal project. The Board is a legal entity set up to administer an organisation whose mission is to "foster and support the Drupal software project, the community and its growth." See for the specific ways it does this.


In order to get new board members ramped up in time for DrupalCon Denver, the first in-person board meeting of 2012, we need to adhere to the following schedule:

  • Have an open nomination period of 1 week. Potential board candidates submit a form with a description of their qualifications and motivations for applying.
  • Voting period of 1 week. (see below for who gets to vote).
  • 2 candidates are presented to the board for ratification.
  • December 30- January 6 (2 weeks): Voting proposal open for public comment (this post).
  • January 9 - January 13 (1 week): Drupal Association's Election Committee takes community feedback and prepares final voting proposal for Board of Directors, sets up whatever tools are required for election process.
  • January 18: Voting proposal submitted to BoD for ratification (cross-posted to g.d.o). Assuming this is accepted....
  • January 19 - January 27 (10 days): Nomination process.
  • January 29 - February 7 (10 days): Election process.
  • February 8: Elected at-large members submitted to board for ratification.
    That means we need feedback as soon as possible!

Issues to address

Indirect elections

It's important to understand that these elections are indirect. The DA bylaws read:

There shall be two At-Large Directors, who are elected by the community and ratified by the rest of the Board to serve one-year terms.

In other words, the community is electing what are essentially candidates for the board, who are then voted on by the other current board members. The process is similar in this way to the selection of "class directors" by the nominating committee. No formal criteria have been developed that the board might use in voting on either class or at large directors.
In the case of the 2011-12 nominating committee's recommendations, two of the recommended candidates were declined (voted down) by the board. It's entirely possible that one or both of the two community-selected candidates will be similarly voted down. In this sense, it may be misleading to refer to this process as "elections", or at least to refer to it as community elections. It may be more accurate to describe it as a nominating process, to be followed by elections in which the board are the only voters.

  • Can/should the DA clarify in advance criteria by which community-"elected" board candidates would be rejected? Doing so might provide greater certainty for community members participating in the process.
  • What will occur in the case that one or more of the suggested candidates is not accepted by the board? Will the candidates with the next most support be put forward? Will there be new elections?

Name recognition

Vote-based electoral systems are sometimes criticized for favouring candidates who are better known, whatever their merits might be. Name recognition alone is said to be a significant factor influencing voting.
In the Drupal community, certain types of community members and contributors may be more prominent than others, giving them a relative advantage going into elections. For example, someone who contributes significantly to Drupal documentation or to local or regional Drupal community organizing may be relatively invisible to the broader Drupal community. In contrast, a Drupal developer who maintains a widely used module or contributes prominently to Drupal core may have a very high profile and broad name recognition among Drupal community members.
Some Drupal community processes exist that may influence name recognition of individuals. These include:
* Syndication on Drupal planet. An individual with a syndicated blog may have higher name recognition than one without.
* Profiling in the Drupal community spotlight.
The factor of name recognition may increase the relative importance of providing means for candidates to become known to the electorate, through e.g. debates, forums, and candidate profiles.

What should be required for nomination?

One facet of the election process that needs to be decided is how nominations happen. Should prospective board members nominate themselves, or should they be nominated by the community? Or some combination thereof?

Criteria for evaluating options

The DA bylaws state:

At-Large Directors shall reflect and represent the Drupal community at large.

Criteria to evaluate nomination requirements might include:
* is likely to identify candidates with the ability to reflect and represent the Drupal community
* is not overly restrictive--does not pose a major hurdle to Drupal community members wishing to run
* can be easily confirmed
Note that existing Drupal Association board members or members of the DA's advisory board are not eligible for election to at-large seats.
Here are some options, as well as advantages and disadvantages:

Self nomination only

Details: Nominations come from individuals willing to run themselves


  • This eliminates the possibility of adding someone to the ballot who has popular support of the community, but who is unwilling or unable to serve on the board of the Drupal Association.


  • May lead to candidates that do not have support of the larger community

Nomination by others


  • Would help identify people the community would like to see on the board.


  • Could end up nominating people who do not want to serve.
  • Requires a vetting process of nominees so votes do not get cast for invalid candidates.
  • May lead to many candidates.

Nomination by defined Drupal community entities

Entities could include:
* Drupal User Groups
* Teams such as security, documentation, infrastructure


  • Would help identify people the community would like to see on the board.


  • Drupal entities may not be set up to make such decisions, especially to do so quickly.
  • Could end up nominating people who do not want to serve.
  • Requires a vetting process of nominees so votes do not get cast for invalid candidates.

Nomination by self AND/OR others

Candidate can nominate themselves, but must be seconded by someone else. Candidate, if nominated by others, must accept nomination.


  • eliminates the possibility of adding someone to the ballot who has popular support of the community, but who is unwilling or unable to serve on the board of the Drupal Association.
  • help identify people the community would like to see on the board.


  • None. Combines the advantages of two of the other options, and mitigates against the disadvantages of self nomination only or nomination by others.

Qualification to vote

Obviously, one of the most important aspects to elections is who has the right to vote on these members. There are many facets that could be used to determine whether someone is a member of the community or not; some easier to check than others.

Criteria for evaluating options

A key question to consider options against is: who are we aiming to identify by our voting eligibility criteria? The DA bylaws say that the at large directors shall be "elected by the community", presumably the Drupal community.
So who is the Drupal community we're trying to capture in our voting eligibility criteria?

  • This is difficult to define, and not necessarily needed at the moment, but should be recognized that this needs to be defined at a later date.
  • Note that there will be additional elections. It's ok to make decisions that apply for the 2012 election and work out better in future elections. (Agile FTW :P) We just need to be very clear about it.

Constituents of the Drupal community might include:

NOTE: decent consensus that the decision for this election will be an interim decision for the sake of time, and that we will continue to define voting elegibility further for next year.

* Participants in Drupal sites like and (ie. anyone with a D.o account)
* Drupal users - who are these? (difficult to define in a tecnical sense)
* DA members (ie. anyone with a indiv or org membership)

* Participants in Drupal conferences or events.
* Organizers of Drupal events. (redundant to g.d.o membership)
* Owners of Drupal shops and consultancies.
* Members of Drupal user groups. (redundant to g.d.o membership)
* Contributors of Drupal documentation. (redundant to d.o account)
* Contributors of Drupal translations. (redundant to d.o account)
* Volunteers with the Drupal Association.
* Contributors to Drupal code--Drupal core and contributed modules, themes, etc. (redundant to d.o account)
* Financial contributors to the Drupal Association or other Drupal-related projects.
* Drupal contractors, site builders, and Drupal shop staff.
* Drupal user interface designers.

Additional criteria for eligibility tests:

  • Lend themselves to programmatic determination, rather than requiring a lot of manual confirmation. For example, can be used to construct a site with accounts for eligible voters based on available data on *.d.o sites.
    Here are some possible ideas we could use to identify voters, as well as their pros and cons. Other ideas welcome!

Is an individual member of the Drupal Association by a certain date.


  • Guarantees that the person is real
  • Cost for becoming an individual member is relatively inexpensive (inexpensive for developed countries, but expensive for members in developing countries such as China or India)
  • is not overly exclusive


  • DA membership has yet to have any defined rights and, to this point, has only been cast as a way to support the work of the Association. There may be significant pushback from the community along the lines of pay-to-play.

Is a member of


  • Broadly inclusive


  • it's very hard to verify that these are "real people" and not fake accounts.
  • Possible to tarnish the election results by bulk-registering accounts. Though one option could perhaps be to put a minimum time on the accounts, e.g. must be a d.o user for >= 1 year.

Has a "Certified to Rock" rating that exceeds a given threshold


  • Considers numerous criteria in identifying Drupal contributors
  • Highly refined methodology
  • Broadly recognized in the Drupal community
  • Provides readily processed data


  • May favour certain types of contributions over others
  • Exact criteria are not visible to Drupal community

Has attended a DrupalCon in the last year


  • shows active involvement and interest in Drupal


  • would exclude people whose input we value who were busy in the last year and/or cannot afford the travel and entry to the event.

Has attended a Drupal meetup


  • shows active involvement and interest in Drupal


  • very hard to track unless we go by self-reporting in which case it's hard to tell they are not fake accounts

Has made commits to Git


  • Rewards people who help make our software awesome with a say in the board of the Drupal Association


  • Leaves out significant portion of non-developer community members from the voting process.
  • Leaves out important contributors to other aspects of the project, e.g. Documentation, User Experience.
  • Not all commits are equal

Has contributed to

Criteria could include:

  • Has contributed documentation (link to page contributed prior to a given date).
  • Is a manager of a group on (link to group).
  • Maintains a project (link to project page).


  • Recognizes various ways to contribute to Drupal.


  • Relatively difficult to verify--would require either custom data processing or individual confirmation of each voter.

How should the eligibility of voters be determined?

This depends on what criteria we decide to use, but for now here are some ideas.
* On the voting site, programmatically construct a list of accounts for eligible voters based on data available at *.d.o. Assign these accounts a role, "voter", that includes permissions relevant to
* During the elections, provide a means - e.g., an issue queue on - for anyone who believes themselves to meet eligibility criteria but has not already been assigned an account to apply for account creation.

How should the community interview candidates?

Once we have the list of nominees, the community needs to be given a chance to ask them questions, find out more about their stances on various issues and particular initiatives they wish to spear-head as part of the board.

Criteria for evaluating options

  • Allows Drupal community members with a relatively low profile to gain exposure.
  • Enables electors to gain information from candidates on areas of concern to electors.
    Here are some ideas. Of course, these are not mutually exclusive and - time and resources allowing - we could use any or all.

Comments enabled on candidate submission forms

(e.g. "Nomination" node form with comments turned on)


  • Allows drilling in to one candidate to learn more about them.


  • questions (accusations, recriminations, etc.) are directed toward a single candidates.

questions should be asked of all candidates and be open to response from all candidates


  • having an open forum will, if nothing else, give a measure of a candidate's willingness and ability to express theirself


  • Might get uneven coverge of candidates, depending on availability.

All candidates meeting

Have a meeting on IRC/phone that allows for "real time" questioning of candidates by community.


  • More immediate feedback on questions
  • Better chance to "get to know" prospective candidates.


  • Leaves out people who cannot be there a given time.
  • Technology may leave some members of the community out entirely.

Where should the elections take place?

Criteria for evaluating options

  • Access to potentially sensitive data is subject to stringent access control.
  • Work required is feasible within the time and resource constraints.
  • Elector accounts can be programmatically created if/as required.


  • Easily accessible


  • Requires vetting a new module for deployment on, will delay election process
  • About 100 people, likely some of whom will be on the candidates list, have administrative access


  • Already has webform module deployed
  • Fits well, since the elections are for the Drupal Association
  • Easily accessible


  • Off the "main" site
  • About 25 people have administrative access (though likely none who are eligible for candidacy)

A subsite for


  • Single purpose site with the functionality and security required to run the election.
  • Can install relevant modules without worrying about impact on the functioning of D.O or A.D.O
  • Becomes an historical record of board elections and outcomes.
  • Potentially could be used for other democratic and transparency activities such as plebiscites, referendums, committee elections.


  • We have to build and maintain a whole site.

Who should carry out the elections, e.g., count votes?

Criteria for evaluating options

  • Only a small handful of extremely trusted people should be able to view who voted for whom. This preserves the ability for people to vote their conscience, even if that means voting against their boss or a co-worker/friend.

d.o infrastructure team



DA election committee




How should voting work?

Then, finally, on the voting process itself. Here's some ideas, but we welcome others as well.

Edit: Please discuss specifics in this new thread
How should voting work for electing the "At Large" board members of the Drupal Association?

Criteria for evaluating options

  • Input is maximized from voters--the more voters whose preferences are considered, the better.
  • The vote outcome is clear and unambiguous.
  • The electoral system is comprehensible to those participating in the elections.
  • There are available solutions (Drupal modules) to provide the solutions.
  • The voting system can identify additional runner up candidates, in case this is needed if elected candidates are declined by the board.

First past the post (FPTP)

Every qualified voter gets up to two votes of equal weight. They are not permitted to cast more than one vote for a single candidate. The two candidates with the most votes (simple majority) are elected.
For more information on this voting system see


  • No need to sift through votes and perform calculations on first vs. second choices or similar voting mechanisms, a simple, anonymized count would be sufficient.
  • Everyone universally understands how this works


  • A candidate with the MOST votes doesn't necessarily represent the MAJORITY of voters.
  • People tend to vote for candidates most likely to win to prevent wasting their vote.
  • FPTP is a widely criticised voting system.

Instant Run Off Vote / Preferential

Voters rank all candidates in order of preference. The candidate with the least number of votes is eliminated, and the 2nd preference of those votes is transferred to the other candidates, and so on, until one candidate receives an absolute majority - or 50% +1 of all votes.
For more information on this voting system see


  • Ensures the outcome is more representative of the will of more voters.


  • It is more complex to calculate the outcome (Note: Decisions module has implemented an instant run off algorithm)

Questions for candidates

What information should we ask of candidates? This might form the basis e.g. of an information sheet that all candidates are asked to fill in, with their responses being publicly accessible as a basis for evaluating them as candidates.
* Name
* Where located (e.g., city and country)
* user name, if applicable

Resource needs

For the elections it looks like we'll need a range of web elements that may include some or all of the following:
* A questionnaire for candidates and a publicly visible display of results.
* Likely solution: Webform module.
* A forum for for candidate questions.
* Core forum module?
* One or more real time meetings.
* Video conferencing?
* A voting system
* If first past the post, ?
* If instant runoff/preferential perhaps the Decisions module?

TL;DR (aka, The Short Version)

We welcome community thoughts on the following questions as they pertain to filling two community-elected board positions for the Drupal Association:

  • How should nominations work? Should interested parties self-nominate for an at-large position, or should we take suggestions from the larger community? Other?
  • Who should be able to vote during elections? Anyone with a account? Anyone who's a paid Individual Member of the Drupal Association? Or some other criteria?
  • What should the community "vetting" process of prospective candidates look like? Comments on individuals' applications? A forum of some kind for the community to raise questions/issues and offer all candidates an opportunity to respond? Some kind of "real-time" meeting?
  • Where and how should the actual elections themselves take place? Webform module, locked down to only a select set of members to view results? A public voting process on Twitter or IRC? What are your ideas?
    Thanks very much for your participation in a very important step for the Drupal Association's community accountability!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web