Drupal Association improvements to Drupal.org

I know what it feels like to have your hard work critiqued, piles of issues to solve and to deal with some of the hardest discussions and posts we can have. I know the many hours spent, sacrificing time with our loved ones, time without sleep or the so many other things we give up to do our part.

During a Drupal.org redesign sprint at one of the recent cons, there was a discussion at about the branding of other Drupal properties, e.g. Drupal Association, Groups, API, etc.

Specifically, we discussed if the theme for the Association site would use the standard wordmark, or if we would create property specific wordmarks so users have a better idea of where they are. I'm pretty sure this discussion was abandoned in the interest of time and just proceed with using the same header/logo as the Drupal.org theme.

The draft policy, procedures and requirements for bringing *.drupal.org initiatives onto the live sites are published here:

Process for getting changes deployed on drupal.org
Drupal.org development guidelines

Hopefully as ideas are generated and refined through the Prairie Initiative and people start implementing solutions, implementors can be proactive rather than reactive to the process and requirements necessary for improving Drupal.org.

The thing I commonly find with forum/committee based systems is that they become very set in their ways. The systems become very difficult to change, and the hostility within these systems are most often sharp as a knife. Contrasty, open community based systems (like those found in "social networks"), are naturally less hostile, more flexible, faster to change with the tide, and able to meet a the needs of a much larger target audience.

This document is an attempt to reduce duplication, increase information accessibility and provide additional flexibility. In addition it will attempt to explain a system which will increase collaboration and decrease hostilities towards change. Thus promoting a healthier environment that accepts rapid change and reduces

I have seen, and even proven that the way in which a system is built directly effects the culture that is within that system. Thus carefully made systems tailored to their audience actually promote growth, improve communication, promote change, reduce hostility and reduce information duplication.

One of the big goals of the drupal.org redesign is to make it easier for end users to find the right modules for the site they're trying to build. With over 5,000 contributed modules, many of them providing similar functionality, it can be extremely difficult to choose. One method is to try to assess the "health" of the module, by how actively it's maintained, used, supported, etc.

One approach to gauging health is posted at Project ratings and reviews for drupal.org redesign. While that proposal deals with subjective factors, this post addresses objective facts about a module that can be computed and displayed for all projects hosted on drupal.org. While no single metric can tell you what module to use, and some knowledge will be required to make the best use of this data, it's important to make these statistics more readily available on drupal.org to empower users to make better decisions.

The redesign prototype for project pages includes the introduction of a sparkline showing the "Activity" for each project. The details of this activity chart weren't specified at a technical level during the design phase, but the spirit of the design is that they wanted more ways to visualize the health of a project. As we're implementing the redesign, we've been empowered to provide as many charts containing specific data we think will best help end users make sense of what's going on with a project. Read on for our specific proposal, including what metrics to compute, and some ideas on how those are going to be visualized on the new drupal.org

This will be an ongoing full-time contract (40 hours per week, or as agreed) for the duration of the redesign project. The contract is currently estimated to be 3 months in duration with the possibility of an extension. This is a contract telecommute position.

The Drupal association is a non-profit organization which provides support for the Drupal, web content management, open source project. The Drupal association is an all volunteer organization with thirty permanent members, and a support base of over 1000 financial contributors. We will provide event sponsorship packages for the fund raising activity. You will also receive access to the Drupal association CRM, CiviCRM 2.1. As a fund raiser you will receive direct requests through the event website and be required to follow up via email and over the phone. This is a contract position.

Infrastructure: Development/testing instances

(Discussion in Infrastructure Requirements)

We are still hamstrung by the lack of dev/testing instances.

What we need from dev/testing instances

• A test instance that the public can view and click around on. This will help us build interest and momentum.
• Several dev instances (at least 5) split between developers and themers.
  • Nice to have: Script to roll out new instances on the fly

We need to discuss how we want the d.o redesign project to move forward. One- to 5-day sprints every few months is not a sustainable solution. Maintaining momentum and continuity is nearly impossible.

Initial thoughts:

• Take a cue from the Aegir project and introduce a proper schedule
  • Require weekly time commitments and weekly meetings
  • Initial thoughts: 4 hours per week for at least three out of every four weeks (meaning you can skip one week from every four to catch up on client work)