(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)

I was reading Drupal Confessions with great interest, because my primary job for quite a while now is to help enable the best efforts in the Drupal community to work together to reach new heights. I am really privileged to be able to do this and make a living out of it, it is the job I always dreamed of. I also hope that I am being useful to the Drupal community in doing so. I kept nodding in agreement with the open letter's statements on diversity so I could not get rid of my cognitive dissonance on their connection with reality for several days now. The open letter says "We ask you to fight for us, Dries, to protect us from intolerance, harassment, smearing, bullying, and discrimination, no matter why or where it originates from."

As someone who is getting a paycheck at least indirectly from Dries in the past 10 years, and working as directly with him as possible in Acquia's Office of the CTO for the second half of that period, I have the opportunity to look at his practices in terms of diversity. Which would be the most observable group to learn more from if not his personal department where he directly appoints people?

In the past 5 years I've been closely working with Dries as a remote employee in the Office of the CTO at Acquia, which consisted of 15 people at most at any given time. In this time I worked with at least the following types of people directly in this group (in random order): blind, stutterer, person with ADHD, person with serious sleep problems, person with even more serious sleep problems, divorced, gay, bi, lesbian, asexual, polyamorous, gospel singer, BDSM, religiously raised, atheist, clinically infertile, cosplayer, very tall, short, people from Eastern Europe, Western Europe, US and India, native-borns, immigrants, people in offices, people always working remotely, capitalist, socialist, pacifist, people from a military family, adopting parent, transgender, people with tics, people who don't drink alcohol, etc. The teams I worked on usually had relatively high percentage of women in technical roles. My current team is 50% female, and 1/3rd of the department overall is female. This could not happen by accident.

While none of this represent the whole rainbow of humanity, and it could definitely be further improved, our limited group of 15 people already covered outstanding diversity in my view. Also this is a group that cares, we discuss and live through our struggles and support each other on every step where we can. I would challenge many of those signing the open letter to practice this kind of diversity in their teams. I for one really enjoy the varying values that people brought in and am sad that some of those great people have left to pursue other technical challenges.

In this five years, I never experienced that when hiring people either of these things were considered as a negative or that any person was treated or felt treated badly for any personal life matter. Neither that any of the amazing people who unfortunately left and are covered in the list left because of any of those.

Given that I just cannot get over my cognitive dissonance. Who are being convinced of what?

We started regular Drupal usability meetings twice a week almost a year ago in March 2016. That is a long time and we succeeded in supporting many key initiatives in this time, including reviews on new media handling and library functionality, feedback on workflow user experience, outside-in editing and place block functionality. We helped set scope for the changes required to inline form errors on its way to stability. Those are all supporting existing teams working on their respective features where user interfaces are involved.

However, we also started to look at some Drupal components and whether we can gradually improve them. One of the biggest tasks we took on was redesigning the status page, where Drupal's system information is presented and errors and warnings are printed for site owners to resolve. While that looks like a huge monster issue, Roy Scholten in fact posted a breakdown of how the process itself went. If we were to start a fresh issue (which we should have), the process would be much easier to follow and would be more visible. The result is quite remarkable:

Image

Starting with Drupal 8, we decided to make more rapid innovation possible by releasing minor versions every 6 months that may come with new features and backwards compatible changes. Now that we released Drupal 8.1.0 and almost 8.2.0 as well, how did we do? Also what else is possible and what is blocking us to make those moves? What do all the changes mean for how might Drupal 9 unfold?

Dries Buytaert posted last Wednesday The transformation of Drupal 8 for continuous innovation and on the same day I presented Checking on Drupal 8's rapid innovation promises at DrupalCon Dublin. Here is a video recording of my session, which should be good for those looking to get to know Drupal's release process and schedule, as well as how we made it possible to experiment within Drupal core directly with Drupal 8. While I did hope for more discussion on the possibilities within Drupal 8 with the participants, somehow the discussion pretty much ended up focusing on Drupal 9, when it should be released and how much change should it come with.

In my previous post I explained why there will be a Drupal 9 even though we have previously unseen possibilities to add new things within Drupal 8.x.y. Now I'd like to dispel another myth, that initiatives are only there to add those new things.

Drupal 8 introduced initiatives to the core development process with the intention that even core development became too big to follow, understand or really get involved with in general. However because there are key areas that people want to work in, it makes sense to set up focused groups to organize work in those areas and support each other in those smaller groups. So initiatives like Configuration Management, Views in Core, Web Services, Multilingual, etc. were set up and mostly worked well, not in small part because it is easier to devote yourself to improving web services capabilities or multilingual support as opposed to "make Drupal better". Too abstract goals are harder to sign up for, a team with a thousand people is harder to feel a member of.

Given the success of this approach, even after the release of Drupal 8.0.0, we continued using this model and there are now several groups of people working on making things happen in Drupal 8.x. Ongoing initiatives include API-first, Media, Migrate, Content Workflows and so on. Several of these are primarily working on fixing bugs and plugging holes. A significant part of Migrate and API-first work to date was about fixing bugs and implementing originally intended functionality for example.

The wonder of these initiatives is they are all groups of dedicated people who are really passionate about that topic. They not only have plan or meta issues linked in the roadmap but also have issue tags and have regular meeting times. The Drupal 8 core calendar is full of meetings happening almost every single workday (that said, somehow people prefer Wednesdays and avoid Fridays).

If you have an issue involving usability, a bug with a Drupal web service API, a missing migration feature and so on, your best choice is to bring it to the teams already focused on the topics. The number and diverse areas of teams already in place gives you a very good chance that whatever you are intending to work on is somehow related to one or more of them. And since no issue will get done by one person (you need a reviewer and a committer at minimum), your only way to get something resolved is to seek interested parties as soon as possible. Does it sound like you are demanding time from these folks unfairly? I don't think so. As long as you are genuinely interested to solve the problem at hand, you are in fact contributing to the team which is for the benefit of everyone. And who knows, maybe you quickly become an integral team member as well.

Thanks for contributing and happy team-match finding!

Ps. If your issue is no match for an existing team, the friendly folks at #drupal-contribute in IRC are also there to help.

Earlier this week Steve Burge posted the intriguingly titled There Will Never be a Drupal 9. While that sure makes you click on the article, it is not quite true.

Drupal 8.0.0 made several big changes but among the biggest is the adoption of semantic versioning with scheduled releases.

Scheduled releases were decided to happen around twice a year. And indeed, Drupal 8.1.0 was released on time, Drupal 8.2.0 is in beta and Drupal 8.3.x is already open for development and got some changes committed that Drupal 8.2.x will never have. So this works pretty well so far.

As for semantic versioning, that is not a Drupalism either, see http://semver.org/. It basically means that we have three levels of version numbers now with clearly defined roles. We increment the last number when we make backwards compatible bug fixes. We increment the middle number when we add new functionality in a backwards compatible way. We did that with 8.1.0 and are about to do it with 8.2.0 later this year. And we would increment the first number (go from 8.x.x to 9.0.0) when we make backwards incompatible changes.

So long as you are on some version of Drupal 8, things need to be backwards compatible, so we can just add new things. This still allows us to modernize APIs by extending an old one in a backwards compatible way or introducing a new modern API alongside an old one and deprecate (but not remove!) the old one. This means that after a while there may be multiple parallel APIs to send emails, create routes, migrate content, expose web services and so on, and it will be an increasingly bigger mess.

There must be a balance between increasing that mess in the interest of backwards compatibility and cleaning it up to make developer's lives easier, software faster, tests easier to write and faster to run and so on. Given that the new APIs deprecate the old ones, developers are informed about upcoming changes ahead of time, and should have plenty of time to adapt their modules, themes, distributions. There may even be changes that are not possible in Drupal 8 with parallel APIs, but we don't yet have an example of that.

After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed. What would make you move to Drupal 9 then? Well, new Drupal 8 improvements would stop happening and Drupal 9.1 will have new features again.

While this is not a policy set in stone, Dries Buytaert had this to say about the topic right after his DrupalCon Barcelona keynote in the Q&A almost a year ago:

Read more about and discuss when Drupal 9 may be open at https://www.drupal.org/node/2608062

Drupal 8 makes huge-huge strides in terms of reaching more people on the globe by making everything translatable and automating translation downloads and updates from the community among hundreds of other improvements. What about software translation contribution though? We did not make progress on that front in core, but it is not very hard to do as a contributed module.

The Localization client module is available for Drupal 7 and 6. It does two things: it provides an alternate nicer user interface to translate Drupal (modules) and it allows you to contribute to the community right from that interface. Drupal 8 already improved the built-in translation interface considerably, so it made sense to start with porting the contribution functionality and integrate that first. The initial Drupal 8 port of that is available for your testing now!

To try it out:

• Join the https://localize.drupal.org/ team you want to contribute translations to (if not already). For testing, you can use the test language. Or better: just test with good translation suggestions so your reviewers will be happy.
• Grab the Drupal 8.x-1.0-alpha1 version of Localization client. Install the Localization Client Contributor submodule only (you would not be able to install the other one yet anyway).
• The module comes with contribution enabled by default, but you need to set your API key so localize.drupal.org can identify you. Edit your user account on your site and enter the API key there. (Follow the instructions on the API key field on your user account edit screen).
• If you want to grant other people to contribute, grant them the Contribute translations to localization server permission to contribute and tell them to enter their respective API keys on their user profiles.
• Now when you go to the built-in software translation UI it will tell you that all things changed will also be submitted to localize.drupal.org and the submit button will reflect that too, to make it super-clear. If you did not set your API key yet, it will tell you to do that instead.
• Once submitting the translation changes, it will let you know how many strings were successfully submitted and any errors encountered as well. All messages are also logged for later review.

The resulting effect of submitting changes locally are visible remotely by the community as well, yay!

Image

Happy translating! See known issues and report more at https://www.drupal.org/project/issues/l10n_client?version=8.x Further improvements are of course possible, issues are welcome!

In the previous tidbits we covered each language and translation capability one by one. The community translates the software interface on http://localize.drupal.org/ which you can customize with Interface translation. You can translate your local configuration and content with the Configuration translation and Content translation modules respectively. However, actual real life use cases are never clear cut like that. Content shows up with some shipped interface elements, local configuration and content. Menus contain elements from code, content and configuration. It is good to know how these pieces relate so you can translate every piece and know the right place to do it.

Up to date as of March 14th, 2017.

Now that we covered how content translation workflow works in Drupal 8, its time to look a bit at the API side. In Drupal 7 this meant dealing with scary seemingly infinitely nested arrays with language codes, field names, deltas, etc. Drupal 8 makes this a whole lot simpler.

Up to date as of November 10th, 2015.

In the previous tidbit, we covered content translation basics. In short now you can configure translatability on any subtype of any entity type, so for example articles or specific taxonomy vocabularies may be configured to have all their entities support translation. Then each entity structure may be configured on the field and in some cases subfield level to support translation. The question is how does it all work then, what do we do to translate content?

I had the chance two weeks ago to talk about Drupal and Drupal 8 at the Free Software Foundation's conference in Budapest for a whole of 21 minutes. While there is this amazing 63 screen slideshow about all things new in Drupal 8 that I help keep up to date, having such short time really made me focus my message and think long and hard about how to summarize what Drupal 8 is really about for a wide range of people attending. Here is my take in written form.

Drupal has always been amazing as a structured content management tool. With content types and then entities and fields it allows us to really structure our content. Drupal 8 steps up this game several ways. First, it makes more things able to get structured. Whether it is a block or the categorization of content itself, it can be structured further with fields now. Drupal also has a history of using this structural system for flexible functionality. For example, ratings, workflows, user groups, selling content, etc. are all supported with fields (in contributed modules). In Drupal 8, comments are fields too (for example, you can take comments on user profiles) and there are more reusable field types like date, email, references, etc. built in. Best of all everything supports multiple languages and is translatable without further modules required. In short, Drupal 8 is improving on the system's key strength in all directions.

This is amazing for an enterprise because content needs to show up in a lot of places and a lot of ways these days. The more structured the content, the easier it is to pull out and display things for the environment needed. Drupal 8 makes this easy by building in entity view modes for display variants, Views for pulling data in whatever way from entities, and responsive output for flexible display on the web. Integration with third party systems and decoupled site implementations is enabled by web service support. Since Drupal knows so much more about your content structure internally as well, it can also intelligently cache (and invalidate the caches) when needed, and serve pages with much faster perceived performance (enabling the BigPipe contributed module). The markup generated is significantly better for accessibility too.

What about the small sites though? I think the changes are even more exciting there, because they lead to a lot more consistency on the site building front as well. You now use blocks to place everything on your pages (including branding, navigation and even the page title). You can use Views to customize even your administration experience and quick in-place editing and WYSIWYG integration for fields allows you to get further, faster. On top of that, rolling out changes is a whole lot easier with the built-in configuration deployment system.

Drupal 8 also grew the core community manyfold. While Drupal 7 had less than a thousand contributors, Drupal 8 has almost 3300. That is pretty remarkable, because it means the new version starts out with many more people already in the know.

All-in-all Drupal 8 really doubles down on our commitment to structured content and flexible functionality around it with a focus on making it easier to both enter and output that content however it fits, whoever the consumer is. It truly empowers you and me (as the tagline says) to build something amazing, for anyone.