DrupalCon Paris is over. Countless of badly needed discussions and brainstormings happened, and we have a couple of weeks to finalize and clean up all of the new APIs and features we added to Drupal 7. I am highly confident that Dries and Angie will continue to do an awesome job in bringing Drupal 7 home and ensuring that it will be a sane release.
But let's think a bit beyond that. I briefly talked with Dries and webchick about it. On my way home, I dedicated the useless traveling time to that fairly difficult question. Please note that this is preliminiary stuff I didn't sleep over, so it may be wrong to some extent.
In Drupal 7, we completely revamped some APIs, such as DBTNG or AJAX. And, we moved "some" functionality of contributed modules into Drupal core:
- Image (not entirely, it will be rewritten and partially live on)
- URL alter
I'm not even sure whether that list is complete... But the more important point is: These modules are not only in the top 20 of contributed modules. They also belong to the list of modules having the largest issue queues on drupal.org. Which we basically also moved into core for Drupal 7.
Although there may be a few more Drupal contributors that look at core's issue queue and do an incredible job in answering support requests as well as ensuring that some bug reports are not bogus, Drupal 7 will ship with a fair amount of complexity that only a very small group of people really groks. Following up on issues for Drupal core now requires a very good understanding of the APIs and exposed/provided features. Which makes the group of people even smaller, because the functionality is covered in the API documentation and handbooks, but not necessarily in a way that allows new contributors to dive in, quickly understand it, and change it.
Yes, we don't do roadmaps. But I think that chx raised a very good point on the development list recently: We all want to see Views in core for Drupal 8. In addition to that, I would see the following points that would be worth to focus on:
- Views in core
- Flag in core (allowing for simple business logic in completely custom ways)
- Rules (or something better) in core
- Enhance the entity/object handling (further steps towards the ever wanted Data API)
- Make arbitrary objects, variables, and strings translatable (basically, but not really, i18n in core)
- Revamp the help system (perhaps, but not necessarily by Advanced Help in core)
- Revamp the filter system
- Revamp the user interface
In general - and I know that mentioning this will lead to objections - these steps will take us some major steps closer to eliminating the developer for many, many Drupal sites and use-cases - primarily regarding a lot of simple/stupid stuff. At the same time though, we not only move the largest issue queue on drupal.org to core, but we also move one of the most complex APIs into core.
By doing so, we will advance on the list of APIs a developer has to fully grok to provide something useful for Drupal core development. Currently, there are only a few developers that really grok the innards of Views. Adding Field API, DBTNG, Internationalization, and other stuff to that, the list of people who are actually able to approve or reject an approach taken in a patch vastly decreases.
Of course, we have peer-reviews. But peer-reviews only work when there are sufficient people who can validate and approve an approach. As outlined in the revised Drupal learning curve (which I want to cover in more detail in a separate post), we always have been low on people being actually able to provide a certain level of trustworthiness to Drupal core committers.
That said, becoming elevated as a Drupal core committer is most probably entirely different to what most people think of. I guess that many people think that being a Drupal core committer means to have some kind of power. But it's absolutely not. It is entirely different: Drupal core committers mainly react on all kind of stuff that is put into their "queue". It is about ensuring top quality for Drupal whenever someone thinks that something can be committed - and that something was actually reviewed and tested by the community (RTBC). And, most often, it is not ready to be committed - due to coding style issues, introducing DX WTFs, UX WTFs, theming WTFs, missing documentation, or whatnot. You don't have any time to play "king" at all (and you'd get sued for trying that anyway).
This basically means that anyone who's playing "core committer" mostly gets pulled into issues that are marked as RTBC, and mostly saying "no" to all kind of patches until they are really ready. It also means to not really touch issues/patches that are marked as "needing review", because those issues require peer-review from other community members and sub-system maintainers first, so Drupal core committers can concentrate on patches that are really considered to be ready.
In effect, that means that anyone who is elevated into core committer business is (potentially) pulled out of the already small group of people that review all kind of core patches (and are actually able to review all kind of core patches). At the same time, pulling out someone of that group of people who can provide quality reviews means that we most likely will commit patches, which this group of people is able to understand. But which are not necessarily understood by any other developers who try to contribute to Drupal core.
Which brings us to the point of documentation. While some parts of the existing documentation are pretty good, there are major parts of Drupal core, which are not documented in a way a developer could similarly lookup a topic and understand it easily (especially DBTNG, Field API, and menu system -- I'm NOT talking about the handbook pages that exist for implementors; I'm talking about the actual API/framework documentation). Take t() as an example: Very good documentation for developers who want localize strings, but not a single word about why it works that way (especially regarding get_t()).
Hence, when new contributors try to figure out how to change some code or even altering an API, they are stuck with either asking "dumb" questions in the issue or IRC to gather the reasoning for why a certain API works like it currently works. You want a really serious proof?
To summarize the macro-level challenges we need to master:
- Raise experience and knowledge of existing contributors
- Better documentation to allow people to grok and contribute at all
- Get more people into core development and peer-review business
Which finally brings me to my proposal for the next development cycle:
For Drupal 8, we may want to pick a novice or relatively new Drupal core contributor, who has a basic/certain understanding of sane APIs, DX, UX, patch reviewing and communication skills, and sufficient time to dedicate for maintaining Drupal core only.
What I mean is actually: Someone who does not understand the (recently added?) APIs yet - like many, many other potential core contributors, too. To get an API patch in, we would have to ensure that this maintainer (and thereby many other developers) actually understands the consequences of a patch by reading the patch. Which equates into: Decreasing the barrier for contributing to Drupal core, and therefore, allowing more people get into the peer-review business.
Lastly, as you may have noticed, this post is mainly about API/in-depth challenges. After being done with brainstorming, I actually figured that all of this does not apply to usability/interface issues at all. Most of those issues (putting IA changes aside) are actually touching "simple" code only. Which means, we already have a slight separation between the Drupal framework and Drupal CMS/application. Which also means that we could be brave and assign separate Drupal core maintainers for the former and the latter (while the outlined approach would then be kinda reversed, meaning that there would be someone highly-skilled for the UX + other stuff, and someone less-skilled for the framework area).
Just some thoughts.
I figure that an approach like this would probably nuke the entire (not really existing ;) list of potential candidates of core committers for Drupal 8, but at the same time, we all suffer from too few core contributors, peer-reviewers, and potentially even sub-system maintainers.Submitted by sun on 7. September 2009 - 16:47