You are here
In June, Jacob Redding, our Executive Director at the Drupal Association, decided that it was time for him to transition out of the Executive Director role to pursue new challenges. Hence, the Drupal Association Board of Directors started a search for a new Executive Director. We have had some very promising conversations, which we feel will lead to a strong placement that will strengthen and grow the Drupal Association and the community.
The Board understands the importance of the Executive Director search and is conducting it with diligence and thoroughness. Since that means there is a chance that the next Executive Director will not be secured by Jacob's departure, the Board has worked with the Association staff to implement a continuity and transition plan for the organization. For the next four months, Megan Sanicki, former Director of Sales & Business Development at the Drupal Association, and Jacob Redding will both serve as Managing Directors of the Association. Megan has already worked closely with Jacob over the last two years to build the Drupal Association and set direction. In the event that there is a gap of time between Executive Directors, Megan will be well prepared to bridge that gap and ensure operations continue without missing a beat. And, in this new role, she will focus on optimizing Drupal Association operations, so we will be positioned for the new Executive Director to start strong on his or her first day.
Please welcome Megan to her new position at the Drupal Association.
Views is the #1 most-used contributed module, installed on nearly 70% of all Drupal websites. The ability for non-developers to create listings for pages, blocks, calendars, photo galleries, and more through a web interface, complete with developer-friendly features such as caching, is one of the primary differentiating factors that makes Drupal shine.
While Views has excelled as a contributed module, bringing Views into Drupal core is now a clear strategic decision. Having Views in core will present many advantages:
- Consistency: Many disparate, legacy solutions are currently used for data listings in core modules. Converting these listings to Views will both improve the Drupal developer experience and make it easier for site builders to customize their sites.
- Learnability: First-time users of Drupal often don't realize what is possible with contributed modules. Having Views in core will mean that new site builders can more quickly understand Drupal's capabilities out-of-the-box.
- Release cycle: The stability of Views has in the past been an indicator of when the community considers a release of Drupal "ready". Drupal 7 usage did not start to increase until a development version of Views was available for D7, and it did not pass Drupal 6 usage until Views was stable.
- Contributor experience: Hundreds of contributed modules rely on the Views API, so these modules are blocked on Views for each release.
- Stability: If Views is in core, changes that cause Views regressions will be core release blockers, and Views bugs will be treated as core bugs.
A grassroots Views in Drupal Core initiative (VDC) was announced back in May. In the meantime, the team has been very busy with getting the necessary pre-requisites into place. These include various dependencies from the CTools project, as well as a Drupal 8 port of the Views module in contrib.
Unlike previous initiatives, Views in Core has an initiative team, rather than a single initiative lead. That team consists of:
- Earl Miles (merlinofchaos) -- Views creator, VDC chief architect
- Daniel Wehner (dawehner) -- Views maintainer, VDC technical lead
- Jess M. (xjm) -- top D8 core developer, VDC patch review & QA, contribution facilitator
- Tim Plunkett (tim.plunkett) -- top D8 core developer and Views contributor, senior VDC developer
- Damian Lee (damiankloip) -- top Views contributor, senior VDC developer
In addition to these people, over a dozen other developers have also contributed to the initiative with the team's coordination and guidance.
For more information about the Views in Core initiative, check out Earl's report on VDC. It provides a detailed roadmap on what needs to be done to get Views in Drupal 8, and information about how you can help.
I've acquired other companies, but the sale of Mollom to Acquia, was the first time I sold a company of my own. Being the seller felt quite different. It's a interesting mixture of satisfaction tinged with loss. During the negotiation phase you feel joy and excitement. Then you feel frustration as you go through the due diligence process. It's a lot of work. Eventually, the day you hand over the keys you feel like you sold your baby. At the same time, you feel a sense of achievement.
Selling Mollom was a life-changing moment. Not because it was a big financial transaction (it wasn't), but because it proves that I was able to bootstrap and grow a company, steer it to profitability, and successfully exit. It was a great experience, because I know that at some point, I'll have the desire to do that again.
Earlier this year, I posted about our first Drupal Association community elections. We introduced the community elections with the goal to make sure that the Drupal community is always well-represented on the Drupal Association's Board of Directors.
Well, the time has come to run our elections again. Nominations opened on 1 September and were open for two weeks. 18 people from the Drupal community put themselves forward as candidates. Please have a look at the election candidates. Voting will be open from September 24 to October 7 but now is the time to engage with the candidates.
Who can vote?
You are eligible to vote if you have an account on drupal.org, logged in during the past 12 months, and created your account before August 31 this year when the election was announced. Once voting opens, you can login at http://association.drupal.org and rank the candidates in order of preference.
How does voting work?
Voting uses the 'instant runoff' method powered by Drupal's own decisions module. For more information about this method of voting, watch this helpful YouTube video which explains it with post-it notes!
On Friday this week, I will be giving a keynote at Symfony Live London. The event is being hosted by our friends at Sensio Labs UK. For those not familiar with that name, Sensio Labs are the original creators of the Symfony framework. The event, which runs over the course of two days (13-14th September), promises to provide some fascinating insights in to the world of Symfony.
Symfony is a reusable set of standalone, decoupled and cohesive PHP components that solve common web development problems. As most of you know, we have incorporated Symfony components into Drupal 8. We are enhancing our strong architecture, with another strong architecture. It is a big initiative that we have been working on for many months.
Given the importance of Symfony for Drupal, it is great to see our two communities collaborate. Events like Symfony Live London are an ideal place for that to happen. I look forward to seeing you there!
Note: some of the information on this page is out of date. For the latest information about how Drupal releases are managed, see http://drupal.org/core/release-cycle.
In talking to Drupal developers at DrupalCon, it was clear that there are some questions about the Drupal 8 feature freeze and code freeze. Questions like: What can we still work on after feature freeze? When do I start porting my Drupal modules to Drupal 8? When can I start testing Drupal 8? Let's address these questions and more in this blog post.
In addition to that, I am aligning our use of alpha and beta releases more inline with industry standards and changing the date of the code freeze, to leave more room to work on improving coherence. Lastly, I also wanted to document my expectations for contributed module developers/authors -- when they are expected or encouraged to do what.
During development phase (now to December 1)
Here are things we do while we're still in development; we aim to prioritize new features and major API changes.
- New features and major new APIs.
- Initial conversions of major new APIs, to ensure additional features are not needed to support them.
- Refactoring required to unblock additional functionality.
During feature freeze (December 1 to April 1)
The goal of the feature freeze is to improve the implementation of existing features and to improve consistency and coherence of core by removing special cases, and unifying duplicate ways of doing things by converting core to use new APIs, etc.
During this phase we stop adding new subsystems. Refactoring of existing subsystems, smaller API changes and API additions are allowed if they help improve consistency and coherence of the existing functionality or are necessary in order to resolve specific critical tasks and bugs.
For example, the following are still welcome and encouraged during feature freeze:
- Completing conversions of
variable_X()to CMI, and removing the variable system.
- Optimizing and cleaning up bootstrap by refactoring page caching and session handling to use Symfony components.
- Better integrating features added before feature freeze (e.g., integrating an existing Layout UI with existing context-aware Blocks, or Views with EntityFieldQuery).
We will start rolling alpha releases during the feature freeze. Contributed project authors who want to help improve the core APIs to better support their projects, can use these alpha releases to begin porting their modules, themes, and distributions. Core developers seek feedback and suggestions from contributed project authors on how to streamline the core APIs.
During code freeze (April 1 to RC1)
The goal of the code freeze is to fix remaining bugs, and prepare for release. Improving coherence of the code base is no longer the goal. Hence, we discourage refactoring, and shift attention from things that are nice to do to things that we must do.
From the code freeze on, we will roll beta releases. Contributed project authors should use the beta releases to port and improve their projects. We encourage contributed authors to start early in the code freeze, as we can still make API changes, if necessary, to work around problems.
Site builders are encouraged to test new installations of Drupal 8 on their development servers.
From code freeze until RC1, we want to do this:
- Improve the Drupal 7 to Drupal 8 upgrade path
- Performance optimization
- Security hardening
- Minor UI improvements
- String and documentation improvements
- Other tasks that didn't get done by code freeze, but that core committers consider necessary; these will likely be marked as ‘critical tasks'.
Release Candidate to Release
We release a first Release Candidate when nearly all critical bugs and tasks are fixed, and a Drupal 7 to Drupal 8 upgrade path is functional. We aim to do this at least two months (around July, 2013) before the scheduled release date (around September, 2013).
We encourage Drupal 7 site owners to test the upgrade path and test contributed modules on their staging sites. We also encourage all contributed project authors to finalize their ports, with the goal of stable releases by Drupal 8.0's release date.
Our guiding principles during this phase of development:
- We try not to change Strings in order to preserve translator efforts.
- We try not to change UI in order to preserve documentation efforts.
- We try to support RC to RC upgrades, in order to help early adopters.
- We try to avoid breaking APIs except in the case of a critical issue.
Special thanks to Nathaniel Catchpole (catch), Angie Byron (webchick), Alex Bronstein (effulgentsia) and Moshe Weitzman (moshe) for their input. I'll continue to evolve these guidelines so more feedback is always welcome.
Very exciting news from the White House today.
Last night President Obama fulfilled his promise to release the code behind "We the People", a Drupal-based application that enables the American people to directly petition the President of the United States on issues they care most about. The release follows a commitment the President made to the United Nations to share the technology behind this platform “so any government in the world can enable its citizens to do the same".
In October of 2009, WhiteHouse.gov was relaunched on Drupal. Two years later, the White House launched We the People on Drupal, a big step forward for Open Government. While governments haven't traditionally recognized the importance of the grassroots, word of mouth organizing that thrives on the Internet, We the People encourages grassroots citizen engagement.
Even more exciting is that if you are an Open Source developer, you can get involved with improving how your government actually works. Needless to say, I'm thrilled to see Open Source and Drupal changing the world in a positive, powerful way.
The newly released code is packaged as a Drupal install profile. The profile is currently tailored to the White House's website but every Github member can issue pull requests to make it more generally useful. The Petition install profile can be cloned, forked or downloaded from the White House's Github repository.