Knokke-Heist
Spark update: ready for alpha testing
The Spark distribution is a Drupal 7 distribution which aims to prototype cutting-edge authoring experience improvements that we hope to propose for inclusion in Drupal 8 core. Since we announced Spark back in May, we've shown videos of prototypes of inline editing, responsive layout building and mobile administration. The rest of the Spark team (Angela Byron, Kevin O'Leary, Wim Leers, Gábor Hojtsy, Jesse Beach, Preston So and Dharmesh Mistry) has also been working hard to make these designs a reality.
There has been a lot of great progress over the past months, and with the release of Spark 7.x-1.0-alpha4, Spark is now ready for some community testing! Each module/theme that Spark builds upon is a separate, standalone contributed project that can be integrated into existing sites. This alpha release includes:
- Inline Editing, courtesy of Edit module. You can click into a node, switch the “View / Edit" toggle in the toolbar, and then click directly into any field to edit its contents, instead of having to be redirected to the backend.
- True WYSIWYG, courtesy of Aloha Editor. Edit your rich text with your theme's direct styling through the inline editor. It even works with images + captions, links directly to content in the site, and has basic support for tokenized strings.
- Responsive Layout Builder, courtesy of the Layout and Gridbuilder modules. You can configure layouts for separate breakpoints (e.g. Mobile, Tablet, Desktop) and even define your own grids for them to snap to. These technologies layer on top of Panels,though it's been architected so it could be integrated with other layout solutions as well.
- New admin theme, brought to you by Ember. This brings some nice light styling on Drupal core's Seven admin theme as well integrating the Admin module to better support mobile devices. A more fleshed out mobile toolbar and administrative experience is slated for implementation soon.
If you'd like to try the distribution out without downloading and installing it, check our demo site at http://demo.sparkdrupal.com. (Note that since this site is open to anyone, it might look a bit funny at any given time. If things are really broken, please check back later.)
There is still much to do, but hopefully this release will provide a good understanding of the direction Spark is taking, and what we hope to propose for inclusion in Drupal 8 core. We greatly welcome feedback, bug reports and patches in the Spark issue queue.
At DrupalCon Munich next week, we'd love to talk more about how we can move some of these things into Drupal 8 core. We've setup various Spark sessions and BoFs at DrupalCon Munich to plan and brainstorm about this.
Spark update: WYSIWYG editing for Drupal
After a lot of discussion and testing, we decided to adopt the Aloha Editor as the WYSIWYG editor for Spark, and possibly for Drupal 8 core. Check out Wim's blog for the details. In short, it is the best HTML5 based WYSIWYG editor; fast, well-written and future-proof.
Here is a screenshot of our latest designs of how we envision integrating the Aloha Editor in Spark on a mobile device:
By tapping into a rich text field such as Body, a toolbar comes up with two tabs with editor buttons below: Format (containing buttons such as Bold, Italic, Left/Right Align, and Lists) and Insert (for Links, Images, and the like).
I also wanted to give a big thank you to Haymo Meran, creator of Aloha Editor and Director of Product Experience at Gentics Software GmbH, both for hosting a Drupal/Aloha collaboration sprint at his company's offices in Vienna last month, and also for changing the license of Aloha Editor to GPLv2+ (from AGPLv3) so that it could be used with Drupal!
It's an incredible gift to the Drupal project and the Open Source community at large. Thanks!
Mollom acquired by Acquia
We're excited to announce that Mollom has been acquired by Acquia.
For the foreseeable future, Mollom will continue to be offered as it is today. I will continue my role as general manager of Mollom, Ben will continue to lead the development of our products and the Mollom team will remain unchanged. If you are a user or customer of either Mollom or Acquia, everything will remain exactly the same.
When Ben and I started Mollom almost 5 years ago, we wanted to do something important. While most people were trying to figure out the social web, we were paddling out ahead of the wave, knowing that many websites would soon have to deal with increasing amounts of spam and content moderation. In the past five years, we have helped tens of thousands of people fight spammers on their websites, including some of the world's leading organizations.
We have blocked almost a billion spam messages since we started. It has been very rewarding for us to see that we have helped make the web a slightly better place. At the same time, we also built a healthy business. We successfully bootstrapped Mollom, and organically grew a team of 6 people.
The social wave keeps on growing; we're helping more and more people and organizations every day. But now that social wave has grown so big, we can't rest on our laurels. There are more business opportunities to explore, some of which we have been working on for a while.
At the business level, it made a lot of sense to merge Mollom into Acquia. Ben and I were looking to raise capital for Mollom to help fund future product development and expand our operations. It was clear that it would require a long-term commitment of my time – just at the point when I wanted to focus more on promoting Drupal globally and driving Acquia's growth and expansion. By having Acquia acquire Mollom, I can still be a part of Mollom, and Mollom could receive the resources to accelerate our efforts and create an even more exciting future for Mollom. It also allows me to double down on Drupal and Acquia. In short, I'm really excited to have Mollom as part of the Acquia family.
Keep an eye on us!
Spark update: mobile administration in Drupal
Today, I'd like to share an HTML/JS prototype we've created for a mobile toolbar and dashboard for Drupal that we hope to include as part of the Spark distribution and then propose for Drupal 8 core as part of the Drupal 8 Mobile Initiaitve.
Drupal 7's default administration tools (e.g. Toolbar module and Shortcut module) were not designed in a “mobile first" way, and as such can be difficult to work with on tablets or smartphones. For example, here is a screenshot of what happens to the Toolbar and Shortcut modules when using a responsive version of the Bartik theme on an iPhone:
On an iPhone or other mobile device, the default Drupal 7 toolbar and shortcut bars both wrap, taking up nearly a third of the screen.
Kevin O'Leary from the Spark team has come up with the following design. The toolbar design in particular takes heavy inspiration from efforts by Lewis Nyman and his mobile navigation prototype.
We set out to do justice to the complexites of Drupal's administration layer while accounting for the constantly evolving universe of devices. We think what we've come up with is scalable, responsive, and usable.
Here is Preston So, author of the prototype, demonstrating the functionality in a short, 7 minute video:
As we begin work on this feature, it will live at the Mobile friendly navigation toolbar project as a contributed module for Drupal 7 first. If these changes are well-received, I hope we can target this functionality for Drupal 8 core, as a replacement for the Toolbar and Shortcut modules.
Fifth birthday Axl
Proposal from first Drupal Governance Sprint
(This blog post is jointly written by Angela Byron, Randy Fay, Greg Dunlap, David Strauss and Dries Buytaert.)
As mentioned last month, on July 16 - 17, 2012, several community leaders in the Drupal project sat down with several community leaders from other open source projects and tried to hash out a governance structure to support the Drupal community's continued growth. "Governance" in this case, encompassing all the things we do to organize ourselves, make plans and decisions together, get things done, and resolve conflicts.
Here are the proposals we came up with, and we are actively seeking community feedback on the ideas within.
What problems are we trying to solve?
We began the sprint by brainstorming a list of problems we're hitting, given the scale of our community. This list included items such as:
- No obvious answer to the question, "Who can make a decision here?" and as a result, important decisions can get stale-mated, or in the worst case leave smouldering craters where a healthy, functioning community used to be.
- Because the Code of Conduct punts on the topic of conflict resolution, a handful of already swamped individuals get tapped on an ad-hoc basis to intervene in conflict situations. This both burns out those individuals, and also leaves the vast majority of the community who don't know who those individuals are with no conflict resolution path apart from "repeat what I already said, but with more volume".
- While our "do-ocracy" model generally works well for our community, it can also lead to situations like "Tyranny of the person with the most time on their hands." We need ways for smart people who can't be on IRC 18 hours a day or read 300+ reply issues to participate and be respected as equals.
Over the course of two days, Drupal community members Dries Buytaert, Angela Byron, Randy Fay, Greg Dunlap, and David Strauss met and discussed a variety of these and other governance topics, and we also received input from Jono Bacon, community manager for the Ubuntu project, Jared Smith, former project lead of the Fedora project, and David Eaves.
Steve Edwards also recorded a podcast about the Governance Sprint; it provides more background on what problems we are trying to solve.
Overview of proposed changes
We propose the creation of a number of "working groups" that essentially make more explicit community structures that already exist. Each working group would consist of ~5 people, appointed by Dries, in charge of collaborating with the community in order to establish effective policy. Each working group will have one "lead" member (chair) who communicates major items and works with Dries. Some working groups will have a set duration (e.g. life cycle of a Drupal core release), others may have terms. Dries, as project lead, also reserves the ability to terminate a group at any time if it feels like they are overstepping their scope (charter).
The summary, in essence:
- Establish clearly chartered working groups where currently loosely defined individuals are taking on things that are community-shaping in their scope.
- Empower these working groups to make decisions, so important community governance decisions do not get stalemated. Keep the groups small enough that decision-making can take place efficiently, but large enough that a diversity of opinions are represented.
- Make it more transparent and obvious, to newcomers and community insiders alike, where "the buck stops" with decision-making in our community in various areas, what the structure of the community is, what's expected of them, and who to turn to for help.
"Drupal" groups
The "Drupal" groups encompass areas that touch Drupal core or contrib, or the Drupal community itself. The ultimate "buck stops here" with these groups is with Dries Buytaert, the Drupal project lead.
Community Working Group
Inspired by the Fedora Community Working Group, this group would be responsible for maintaining a friendly and welcoming community, and their charter will likely consist of items such as:
- Maintaining and updating community-governing policies like the Drupal Code of Conduct.
- Helping with mentorship and on-boarding of new community members.
- Ensuring existing community members have their needs met.
- Intervening as mediators in cases of conflict resolution (where the conflict cannot be worked out among individuals first) or burnout.
- Issuing sanctions in cases of extreme policy violations.
In other words, this working group tries to make sure the "people" side of our community is functioning well. It doesn't set technical policy or intervene in any code-related matters; this is the role of the Technical Working Group. The ideal make-up of this group would be community-minded people with extreme amounts of patience, empathy, and diplomacy skills.
Technical Working Group
A corollary to the Community Working Group, this group would set and maintain policies around the technical aspects of our community, including:
- Develop and maintain policies around things such as:
- Establishing best practices and recommendations around bug/issue workflows; for example, strongly encouraging a workflow of idea -> architecture review -> implementation -> code style/clean-up.
- Recommending to the Drupal Association tool changes that will help accelerate contribution.
- Intervening as mediators in cases of technical conflict (where the conflict cannot be worked out among individuals first).
In other words, this working group tries to make sure the "technical" side of our community is working well. "People" problems would be escalated to the Community Working Group. Nevertheless, the ideal make-up of this group would be community-minded people who are also technical, known to be fair, and adverse to making new rules.
Drupal Core
A lot of time was devoted at the sprint to discussing Drupal Core, and how to address some of the challenges surrounding its development. For example, there is currently a lot of tapping of internal networks to move things along in core, and those without access to those networks can feel blocked out. It's also very difficult to get an answer as to whether or not something is "core-worthy" until far too late in its development process, making major feature development a risky affair.
The recommendation from the Governance Sprint is something like the following, which would not take effect until the Drupal 9 development cycle.
Drupal Core Initiative Working Group
This group works with Dries Buytaert, the Drupal project lead, in order to tackle strategically vital initiatives within Drupal core. Membership includes the initiative leads. This would entail a bit more formalized structure, including milestones and progress tracking, bi-weekly meetings among the various initiatives, and so on.
This would be essentially formalizing what already exists today with the Drupal 8 initiatives and initiative leads.
Contributions repository
At the Governance Sprint, we agreed to continue not to impose any additional governance structure on contrib, by design. This allows contrib to be an incubator not only for technical solutions, but also for governance itself.
The exception would be conflicts between maintainers or maintainers and their users which are not able to be resolved among the individuals. These would then go to either the Community Working Group or Technical Working Group, as appropriate.
Security and documentation teams
We have a few overall "Teams" that touch elements of the product, including the Documentation Team and Security Team (we also discussed the establishment of a Support Team). As part of the new governance model, we recommend creating charters for these teams that make it explicit to others what their roles and responsibilities are, how to join, and what is expected of them. It's likely these charters will be modeled after something like the Documentation Team and Leader Responsibilities page.
"Operations / Administration" groups
These groups act in support of the Drupal project and its community. The ultimate "buck stops here" with these groups is with the Drupal Association board instead of Dries. Many of these have a financial impact on the Drupal Association and greatly affect its ability to get things done in support of its mission.
And what about Drupal.org?
Next to Drupal core, this is probably where we spent the most time discussing. Drupal.org is special, in that it straddles both the community side of things, as well as the operations / support side of things. It functions through a combination of numerous volunteers as well as funding via the Drupal Association for support staff and development on major initiatives.
At the moment, the best place to put Drupal.org seems like it's at a halfway point between the "Drupal" and "Operations" sides of things, and for the charter of this working group to include the necessity to work with the Drupal Association and community members alike. Though eventually, for both legal and simplicity reasons, it would be better for this to be located under the purview of the Drupal Association board.
A few areas there was broad agreement on, however, were the following:
- Split off a separate "Drupal.org content" working group from the "Drupal.org webmasters" working group; different skills/levels of trust are needed for managing the content on Drupal.org versus managing access and performing moderation of abuse.
- Identify a much smaller subset of the Drupal.org webmasters group to form policy for this team. Currently, there are nearly 150 members with "site maintainer" privileges, and they often make and enforce policy on an ad-hoc, individual basis. Community members currently encounter very inconsistent experiences in the queue.
- While the Drupal Association doesn't manage these groups, it's generally expected that the charters of these groups will include directives to collaborate with the DA in their policy-making decisions in order to ensure the financial sustainability of Drupal.org.
Next steps
We're very interested in community feedback on this direction, either in comments below or privately. We'll provide an update on the progress at DrupalCon Munich.
We encourage everyone to come and get involved in this discussion. As our community grows, it is essential that we come up with a governance structure that matches our core values and allows us our community to be more sustainable for the long haul.
