You are here
Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.
From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.
One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.
We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.
While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:
- WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
- Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.
For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.
In Drupal core, we use issue thresholds to manage technical debt. Both critical (release-blocking) and major (non-release-blocking, high-impact issues) are considered. When we have more open issues than our thresholds, we do not commit new features.
Currently, we have 27 critical bugs, 41 critical tasks, 155 major bugs, and 149 major tasks. This is more than twice our current thresholds for critical issues, and about 50% more than our thresholds for major issues. We need your help to resolve these issues so that we can resume adding new features to Drupal 8. That would be a very exciting place to get to!
There are many ways to help, including not only programming but also updating these issues' summaries, testing the patches, and making sure the patches still apply. I encourage everyone to collaborate on major and critcal issues, and to consider making them a focus at the DrupalCon Portland sprints.
I'm pleased to share that Alex Pott (alexpott on drupal.org) has accepted my invitation to become another Drupal 8 co-maintainer, to help move along important issues as we gear up to head into code freeze and then release.
Alex has been working in Drupal for almost 6 years. While relatively new to the core development team, he has nevertheless been an instrumental force in the Drupal 8 Configuration Management Initiative (CMI). This development experience has given him a detailed understanding of various underlying Drupal 8 APIs, which makes him ideally suited to the task of reviewing and signing off on highly technical patches. Alex is furthermore thorough and patient in his technical reviews, and he has been a reliable leader and problem-solver during the Drupal 8 cycle. He is also currently taking time off from work, in order to have more time to dedicate to his family and to Drupal. It's a perfect fit.
When catch, webchick and myself were discussing who would be best to join the core maintainer team, Alex's name was enthusiastically +1ed from each of us. Please make him feel welcome!
A couple of weeks ago Acquia, the Red Hat of Drupal, reached out to fellow CMS founder, Matt Mullenweg of WordPress, to see if he would consider switching to Drupal. As luck would have it, this was enticing to Matt. He has long understood the value of the Drupal community and has been looking for ways to leverage our community to make WordPress even better. When Acquia suggested switching to Drupal, it dawned on Matt that this was certainly the easiest way to integrate with Drupal without irritating his webmaster.
"I have always wanted to be part of the Drupal community, where technical expertise is sought after to create some of the most advanced websites. This move demonstrates the synergy between WordPress and Drupal without the possibility of function name conflicts." - Matt Mullenweg
Several months ago I started working with some of our top developers to try to come up with a practical integration strategy between Drupal and WordPress. We had been struggling with this for some time when webchick said jokingly: "It would be a lot easier if they would just use Drupal instead".
To be honest, I felt a bit silly even talking to Matt about using Drupal, but I didn't know at the time that he had been struggling with exactly the same goal and the same problems. webchick's inadvertent idea has ushered in new possibilities for innovation and frankly this is such a fundamental change for us I can't even imagine the world as it was before.
I am very excited about this collaboration. WordPress and Drupal form a killer combination that can't be beat in today's CMS market. I can hardly wait for the WordPress developers to get their drupal.org accounts set up, so we can work together in ways that were never possible before. I also suggested xjm to setup extra "WordPress tables" at the DrupalCon Portland code sprint.
A new Drupal module has been created to ease the transition. The "WordPress_iframe" module will be available on drupal.org soon. It facilitates a rapid integration of existing WordPress sites into their Drupal counterparts. We are excited about the debut of this new module because it embodies the Drupal community's open acceptance of this partnership while it allows us to roll out literally millions of these new Drupal/WordPress sites over the coming weeks.
As part of the agreement, Matt didn't want to completely move away from the WordPress branding, so we have incorporated it into Acquia's logo. Phonetically Acquia is pronounced ah-kwee-uh, so we've swapped out our Q for the well-known WordPress "W". The name is still pronounced "ah-kwee-uh" but will now be spelled "Acwuia". This visually puts WordPress right in the center of our logo - exactly where it belongs. This is WordPress, powered by Drupal.
We are very proud of this partnership and look forward to serving many more customers as a result. You can expect many more great things from Acwuia coming soon.
Matt, your Red Press of Drupal t-shirt is on the way. Let's stand together as brothers, united in Drupal!
Today I'm excited to announce that we've released the next generation of Mollom - our Content Moderation Platform. For the past five years, we have worked hard to help companies stay ahead of the curve when it comes to content moderation. With today's release, I feel like we've secured our place as the leading enterprise-ready content moderation system.
With over 2 years in development, and 600 beta users, the new content moderation platform is built to help companies handle extensive amounts of user generated content with ease. The main features of the Content Moderation platform are:
- Easy team management. Site admins can add moderators, assign privileges, and monitor how moderators are performing - keeping an eye on productivity while trusting that no malicious content is making it to their site.
- Fast moderation. If we know it's spam, your team never sees it. If we're sure it's good content - we'll publish it to your site. For the content we're unsure about - moderators now have a very easy user interface where they can view the contributor, their comment, and their reputation, spam, and profanity score all within seconds. They can approve or decline, and even take bulk actions to speed things up.
- Custom filters. The system allows each user to create custom filters so they can focus on a specific subset of commenters. If they only want to see users with low spam and profanity scores - creating a filter takes just a couple seconds and they now have a customized view.
- Multi-site management. All customers can have from one to hundreds of sites in their system - which makes moderation for big brands with multiple site properties very easy. Adding a site takes just a couple minutes, and customers can view analytics separately across all site properties.
I'm really excited to finally show this off to the world, and continue to help more companies embrace social without fear!
This Saturday and Sunday, March 9-10, over 30 locations around the world will participate in Global Drupal Sprint Weekend, coordinated by Cathy Theys (YesCT). The sprint weekend is a grassroots initiative for people all over the world to get together and contribute to Drupal. You can join a local sprint, start your own, or participate remotely in IRC.
The sprint weekend is a unique opportunity to make big strides on the Drupal 8 release, and I encourage everyone to find something you are passionate about and dive in. For example, you can help reduce Drupal 8's accumulated technical debt by targeting the major and critical threshold issues, to kick off our cleanup phase and make Drupal 8 stable enough that we can continue to innovate. We're currently at 18 critical bugs, 124 major bugs, 33 critical tasks, and 130 major tasks. It'd be great to see how many of these we can fix by this time next week! :-)
Or, try your hand at upgrading a module to Drupal 8, and provide input and feedback on the "Developer Experience", as well as identify missing or incomplete APIs while we can still change them. You can find resources to help you with porting modules on the sprint wiki page.
Whatever you work on, blog or tweet about it after the sprint is done. Let us know what you worked on. You can also share what worked well for your sprint, or things you learned. Tag your posts with #SprintWeekend so we can use your feedback to help shape future sprints!
Finally, if you're local to the Boston area, Acquia is also hosting an Open Drupal 8 Core sprint in our Burlington office that will target core threshold issues, including work on the Blocks UI. Lots of active contributors to Drupal 8 will be here to help you find something awesome to work on. Stop by!
Last summer, a number of Drupal community members as well as key figures from other major open source projects met in Portland for the first-ever Drupal governance sprint. The proposal from that sprint recommended the creation of a number of chartered "working groups" to better formalize the existing governance of various aspects of the Drupal project, now that our community is at its current scale. We have now chartered the first of these working groups: the Community Working Group. Thanks very much to everyone who participated in the vigorous community discussion and drafting efforts around this.
However, while the governance proposal coming out of Portland provided some fairly solid direction on the governance of the Drupal project itself, it left some pretty big questions unanswered as it related to the governance of Drupal.org. Drupal.org isn't just some ordinary website. While it was originally a small portal with a few hundred members hosted on a friend's shared server, it is now serving millions of page views to over 2 million unique visitors per month, as well as terabytes of data, and is home to almost a million active members, among them thousands of contributors committing code, reviewing patches, improving documentation, etc. at all hours of the day. The old "do-ocracy" model of getting things done on Drupal.org isn't scaling for our community anymore, and lack of clarity around decision-making has cost us repeatedly, in the form of slow progress on the Drupal.org Drupal 7 upgrade, Drupal Association funding challenges and staff inefficiency, and various community volunteer frustrations.
I've therefore spent time over the past few months talking with a number of members of the Drupal Association, various Drupal.org volunteers, Drupal core/contrib developers, as well as other interested parties, in order to determine how to put into place a structure that clarifies the decision-making processes around Drupal.org. The following is the overall proposal for Drupal.org governance we've come up with, as well as links to more specific draft charters for community review.
Note: the finer points of this can be found in http://buytaert.net/files/drupal-governance-plan-2013.pdf.
While "governance" can sometimes sound like a scary word, really it's about coming up with a way to:
- Make decisions fast,
- In as lightweight a way as possible
- Allowing affected parties to have a say,
- With clearly-defined processes and easy to understand decision-making.
Cracking this problem for Drupal.org provides us with less frustration/uncertainty among volunteers, more money and resources funneled into improvements, and better community velocity overall.
Governance mostly comes down to establishing "working groups" around major areas of the project, many of which already have governance in at least an ad-hoc basis. Working groups will consist of a chair, plus 3-5 members who are empowered to make decisions, then a team of N volunteers and/or DA staff to help carry out their tasks/policies. The working groups are only empowered to make decisions as a whole, not on an individual basis.
Drupal project governance / Drupal.org governance compared
For the Drupal project, we are working towards developing a number of working groups related to various aspects of the community (security, documentation, conflict resolution, Drupal core, etc.), with myself as the final decision-maker:
The working groups might be compared/contrasted this way:
|Community working group||Technical working group||Security team||Documentation team||Drupal core X working group|
|Guarantee a friendly and welcoming community for the Drupal project by upholding the Drupal Code of Conduct.||Maintain technical policies, procedures, and standards as required to keep the technical side of our community operating smoothly.||Maintain technical policies, procedures, and standards as required to keep our projects secure||Make sure that we have high quality technical documentation for Drupal, including the Drupal handbook and API documentation||Provide technical leadership and project management for Drupal core development.|
In the case of Drupal.org, however, it makes sense for this final decision-maker to be the Drupal Association, since they are ultimately responsible for the website, purchasing hardware, etc.
The working groups might be compared/contrasted this way:
|Drupal.org infrastructure working group||Drupal.org software working group||Drupal.org content working group|
|Responsible for all infrastructure-related needs of the Drupal project, including the servers, Git repositories, mailing lists, DNS management, e-mail management, network, server access and security.||Responsible for guiding the planning, architecture, development, and maintenance of the Drupal.org websites.||Responsible for maintaining policies around the major content areas on Drupal.org. They also manage the overall look and feel and voice of the website, including its information architecture and design elements.|
Needless to say, groups will often have to work together. For example, to answer the question of whether to keep developing project module or move our collaboration tools to Github, we'll have to get the following groups together: (i) the Drupal.org software working group because it affects the features of drupal.org, (ii) the Drupal.org hardware working group because they may need to host new features, (iii) the technical Working Group because it impacts how we collaborate on software development, and (iv) the Drupal Association Board of Directors because they have to write the check.
Draft charters for review
This is a work in progress. Please help shape the future of Drupal.org governance by reviewing and commenting on the following proposals:
- Drupal.org Infrastructure Working Group
- Drupal.org Software Working Group
- Drupal.org Content Working Group
- Technical Working Group
- Community Working Group (Already formalized)
Our plan is to allow everyone in the community to provide feedback during the next 3 weeks. Then, around the end of March I will post updated drafts based on community feedback, with the aim to finalize the charters by the mid-April.
Onward and upward
I'm really excited about the possibilities for Drupal.org in the future with this governance structure. My hope is that this helps address some of the ambiguity and confusion around the current structure, while at the same time not being overly constrictive.
Thanks in advance to everyone for their participation in helping to shape the future of Drupal.org!