Revamp MAINTAINERS.txt

How did I miss this, subscribing.

subscribe

Subscribing.

(webchick is apparently missing here)

Indeed, that's pretty sad. And it looks like the Drupal 5 and 6 maintainers are similarly missing from the corresponding versions of MAINTAINERS.txt as well.

Clearly this file needs a lot of work.

On #3, this will take me quite some time to compile. My "mind map" of the "core" Drupal core developers probably extends to about 250 people (granted, not all of whom would be in MAINTAINERS.txt). It'd be helpful if someone else took a stab first and I could fill it out with omissions.

Here's a few notes:

defacto maintainers this release. In the case of poll and comment, I'm not sure any of us would actually volunteer to be listed though:

comment.module - me, moshe and yched
poll.module - chx and quicksketch ;)
field_ui - yched
OpenID - Heine and c9...

Properly unmaintained. Some of these may have listed maintainers but otherwise be in 'maintenance' mode. Some have had people working on them, but usually a handful of people doing one off patches each, some I may have overlooked people so please correct:

profile.module
forum.module
block.module
help.module
color.module
search.module
trigger.module
blog.module
translation.module
statistics.module
tracker.module

Remove from list:
-upload.module

This also brings up an interesting question. For something like entity.inc, Frando and I did nearly all the work on the original patch, and I've been trying to respond to bug reports / cleanups since then - however it hasn't had a load of time to bed in, so most of the work was in the initial patch, rather than actually 'maintaining' it as such. A lot of the d7ux patches are very similar, in that a few key people worked on the initial patches, in some cases for months, but they're too new in core for anyone to have a track record of maintaining them post-commit yet. In those cases, should we add those people as the 'talk to this person about X' person? It's quite common for the people who end up maintaining something to be different to the original authors, but I think that's OK - we should be revisiting this list a lot more often than has been happening previously, and shouldn't be shy about replacing people in the list when they move on to other stuff.

What is the purpose of MAINTAINERS.txt? If it's "ask these people when working on a core patch of area X" then you can easily list Damien, Moshe and me as a "jack of all trades" because it's quite likely we can help to some extent with everything and then the deep problems can go to the real domain experts. Or...?

Stark - John Albin.

I think low-level-jack-of-all-trades is covered by 'base system', so would just be a case of adding Moshe in there.

webchick isn't in there yet. I think the Drupal 7 MAINTAINERS.txt should also list 4/5/6 maintainers so it's easy for people to find out.

I'd rather see David Rothstein listed as overlay maintainer. He's certainly more active in the queue than I am. If David doesn't want to be listed, let's leave it blank. I frankly don't have what it takes to absorb all the overlay hate.

Subscribe.

sweet, this will save me some backtracking

So lets look for those maintainers?

IMAGE SYSTEM
Quicksketch

INSTALL SYSTEM
Drumm?

UPDATE SYSTEM
Dww?

MENU MODULE
Pwolanin?

Toolbar - is probally almost primarly a UX item?
Dashboard - same?

Seven Theme
Seutje?

whoah, I hardly did anything to seven :x

Thats why there is a question mark :P, but given that - someone does needs to be appointed maintainer of this. Given that seutje has done most followup patches to Seven I consider him an candidate. But then again, Steef still beign maintainer of Garland kind of points out how not-updated our themes are.

In the language system I'd cite Nedjo if he's available.

Thanks for tackling this, sun. The last time was August 2007 - reference: http://lists.drupal.org/pipermail/development/2007-August/025681.html and http://groups.drupal.org/node/5434

As I said back then, even MORE ideally you would have 2 maintainers per component, especially major components. This could also lead to a sort of buddy/apprentice system, where we could have people getting trained up over time.

As catch points out, revisiting this list more often is a good thing.

Where do the JavaScript/CSS/Library system(s) fall? Anything else we may be missing?

Re:

UPDATE SYSTEM
dww?

in terms of the core issue queue components, the "Update system" is really the DB schema update system, aka update.php. That's not me (although I know something about it and help where possible). I'm really the maintainer of the "Update module" (which was renamed from "Update status" to "Update manager"). Dave Reid currently co-maintains with me. I've been doing my part to keep this aspect of MAINTAINERS.txt accurate as things change:

#447700: Update MAINTAINERS.txt to reflect reality for update.module
#588574: Make Dave Reid a co-maintainer for update status
...

That's already quite enough for my official core maintainer duties. Please don't add me anywhere else. ;)

Thanks!
-Derek

p.s. This "update system" vs. "update.module" business has been a constant source of confusion in the issue queue ever since the thing I maintain was added to core as just "update" instead of "update_status". There's not much we can do about that now, but it sure is confusing. I'd be in favor of renaming the "Update system" component to "Database update system" or even "update.php", but that's a bit off topic for this thread. However, if we're trying to make MAINTAINERS.txt mirror the components, we should name the components something sane, first. ;)

Subscribing. Thanks, sun, and everyone else for pushing this, and trying to create better structures for Drupal development.

I'll add that the areas of Drupal that I have the most interest in and feel very fluent in are:
AJAX System
Form System
Render System
Theme System

There are definitely contributors (some subscribed to this issue) who've done each of these longer, understand the system better, and have contributed more than me. But to the extent that we want more people listed for any of these systems, these are the ones I spend the most time thinking about.

This is a re-roll of #12. Plus I separated modules and themes into two sections, and added all the lowercase modules in #12 as uppercase modules. Also:

• I removed ksenzee from overlay as per #14, since if she doesn't want herself in there, we should respect her wishes. I'm +1 for adding David if he agrees.
• I did not make the change suggested in #15, since sun left it as a question.
• or the ones suggested in #20-#23, since it doesn't seem there's any consensus there.
• or add myself to theme or render system (#28), since there hasn't been any feedback on that yet.

What do you think of this for proceeding? Get this patch to the point where we agree on structure, even if there's lots of ??? remaining, and have that land. Then create a MAINTAINERS.txt issue tag and send an email to the developers list asking people to submit issues with that tag if they want to nominate themselves or others to be added, so that we slowly remove those ???. Seems like it'll be easier to review each one separately than try to get this entire file filled in in a single issue.

Re #25: Do you mean things like the drupal_get/add_css/js() functions? Or the files in the "misc" folder?

Let's be very careful about the level of detail we're doing here. We don't want to go too overboard and make MAINTAINERS.txt un-maintainable, as people enter and leave the project.

Additionally, if we're intending this to be written to the audience of "I don't know who to talk to about $x," let's make sure it's useful to that audience. For example, rather than separating out each individual module, I would group the headings into general categories, listing maintainers and their specialties after.

I'm on webchick's side: a few general sections listing people + their specific area of expertise (if necessary) would be more then enough.

That said, I don't mind being listed in a general section, as chx suggested in #9.

Re: #29: Now that all the "systems" are split out like that, feel free to list me as a maintainer for the "Queue system", too.

#706540: Register all core modules/APIs on drupal.org

This issue might be another good reason to register all modules/apis of core on d.o.: list their maintainers. People might look on the d.o. earlier than in maintainers.txt

I agree with sun about calling out each core theme and module that exists as a top-level folder in "themes" and "modules" (no need to call out number.module separately from field module). I also think it would help people for there to be consistency between system name and .inc file name. With that in mind:

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
+CODE REGISTRY SYSTEM

Can we rename registry.inc to code_registry.inc or rename the system to REGISTRY SYSTEM?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
 FIELD SYSTEM

What is this other than the field module? If nothing, let's move it to the modules section. If something, can we add some text here that answers that question?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
 FILTER SYSTEM

Should we create a filter.inc file and move some function from common.inc into it?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
+LOCKING SYSTEM

Can we rename lock.inc to locking.inc or rename the system to LOCK SYSTEM?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
+QUEUE SYSTEM

system.queue.inc is part of the system module folder. Why should maintainership of this be separate from that module?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
+RENDERING SYSTEM

Should we create a render(ing).inc file and move some functions from common.inc to it?

+++ MAINTAINERS.txt	6 Feb 2010 18:58:10 -0000
@@ -1,63 +1,96 @@
+TESTING SYSTEM

What is this other than the simpletest module? If nothing, let's move this to the modules section. If something, can we add some text here that answers that question?

Regarding #25, I think mfer meant everything related to drupal_get/add_js/css/library()...

Can anyone think of a better name than CLIENT-SIDE CODE INCLUSION SYSTEM: I'd hate to suggest that we should create a client_side_code_inclusion.inc file.

The drupal_add_*() and #attached are very closely linked to the D7 render system, too much to split out IMO.

In fact, we should actually list maintainers of common.inc and system module if that's where functionality lives, then add notes about which bits (filter_*(), drupal_add_*(), drupal_render(), entity_*(), queue.inc etc.). they maintain. If that looks like crap, good, all the more reason to clean it up later, but actually moving that stuff around is Drupal 8 work now.

Field system - yes it should just be listed as a module. We should also remove 'Node system' from the Drupal project components to just leave Node module. This also needs its own issue probably. Ideally components and Maintainers.txt would line up pretty much 1-1.

With testing system, I assume this also means qa.drupal.org. IMO while it's nice to credit people, there's far more infrastructure on Drupal.org than when those roles were added to MAINTAINERS.txt (groups, association etc.) - so we should consider just restricting MAINTAINERS.txt to talking about the actual Drupal code base and list other infrastructure / admin etc. roles elsewhere, rather than leaving people out by trying to be inclusive.

Dude, no. We are not splitting a bunch of files up at this point to make documenting who's not in charge of things easier.

/me coughs at the 189 critical bugs, of which this is not one, since it has never blocked release before and can be done at any time. I'd still like to get it in, though.

Yes this isn't a release blocker. However out of interest I went to look at how many critical issues are for modules or components without a listing in MAINTAINERS.txt

And here they are. it's at least 2/3rds.

I'm not sure I understand this issue. There is no rule that says that every component needs a maintainer.

I'm not sure I totally agree with that premise. Having a dedicated maintainer for a particular area is a double-edged sword.

When I know someone is "in charge" of XYZ thing (let's use SimpleTest as an example), it's valuable to me as a core maintainer because I know to check with them before any major changes, and to sync up with them on major goals, etc. It's also valuable to potential contributors because they have someone to ask for help if they run into something.

On the other hand, since everyone knows that SimpleTest is already covered, they tend to go "Great, that's handled!" and let all issues about it drop completely from their radar, and go do other things. It is extraordinarily difficult for boombatower to find co-maintainers, because the people who could reasonably be co-maintainers are off working on other things that don't have a dedicated maintainer.

I think there is far more value in identifying general subject matter experts who majorly impact core development, and who can receive questions from folks who want to help out and are stuck, since I agree that currently who the actual "core development team" is is incredibly opaque. But MAINTAINERS.txt IMO should reinforce and emphasize that the responsibility for maintaining *Drupal core*, which is greater than the sum of all of its parts, falls to *the entire Drupal community*, not this list of 20-30 people. This is a feature, not a bug.

Here's a clean-up based on #38 and responses. I can accept that creating filter.inc and render.inc and renaming other .inc files are outside the scope of this issue. Therefore, I renamed the system names to match the .inc files (CODE REGISTRY SYSTEM -> REGISTRY SYSTEM and LOCKING SYSTEM -> LOCK SYSTEM). I still believe we have a filter system and render system (without the "ing" suffix) and will open separate issues to create those .inc files and argue that it's not a big or risky change to do so and that doing it would help people pick the correct "component" when filing an issue. But I also won't be surprised to see that bumped to D8. I removed sun as the filter system maintainer as per #3, and I think the #3 comment illustrates the confusion caused by not having a filter.inc file. I agree with #39 that drupal_add/get_css/js/library() belong to the render system and not some to-be-named system (and gosh, if that's what we agree on, a render.inc file would make that clear to the 99.9% of the community that will never see this comment). As per #38, I moved field system to field module and testing system to simpletest module. Now, there's an entry for every top-level folder within "modules". Finally, as per #38, I removed queue system, since I can't find anything outside of the system module folder that belongs to it (though this also means we lose dww being listed as per #35, since I don't think he wants the burden of being listed for the entire system module).

If the two branch maintainers think this issue isn't critical, then I guess it's not. But I think it's a really nice DX improvement, and I see no down-side to this patch landing as-is and follow-up issues created to fill in all those ???. I see this as equally important to all the other documentation we work so hard on.

Oops. I was wrong. I did not remove QUEUE SYSTEM in #46, but I think it should be removed.

I don't really understand the authorize system enough to know whether it warrants being listed. We're not listing the archiver, cache, pager, or session systems, as well as some other things that have their own .inc files, so I'm just not sure what makes something enough of a system to be considered its own system rather than part of the base system or some other sub-system. That said, I have no objections to any of these being listed as their own systems.

I do think we need clarity around the "misc" folder, but listing every .js file separately as suggested in #31 seems like overkill. How about a new section: "misc" folder maintainers with these three items in it:
JAVASCRIPT FILES
CSS FILES
IMAGES

This does have some drawbacks, like if someone files an issue about batch.js, do they pick the "JAVASCRIPT FILES" component or the "BATCH SYSTEM" component (yes, I'm assuming once this patch goes in, we'll want to update the issue queue's "component" options to match). But the reality is that both components are affected, so either choice would be perfectly valid, and whichever is chosen, that component's maintainers can pull in the other component's maintainers if needed.

I'd like to see us pull in people who are being added by this patch in to review this issue so they can approve that addition. I scanned the patch and think that means pulling in the following:
fago
frando
pwolanin
eaton
Everett Zufelt
c960657
quicksketch
Heine
scor
JohnAlbin

If we add the people suggested in #14, #20, #23, and #47, I'd want them reviewing this issue too.

Again, IMO this is way too granular to be useful, and assumes way too much background knowledge (e.g. "system" == a file in the includes directory, or not). It should be something more like:

UPDATE SYSTEM
==========
- Derek Wright ...
- Dave Reid ...
- Jacob Singh ...

Includes:
- authorize.php
- Update module
- update.php

And our goal should be to cluster things around as few functional areas as we can, trying to anticpiate what people would actually be looking for maintainers of.

I'd like to see us pull in people who are being added by this patch in to review this issue so they can approve that addition.

I'm fine with being listed for FAPI. Although I guess I did more work on the render system in D7 than on FAPI, so it might be more appropriate to list me there instead. In a previous version of the patch I saw my name next to the entity API, which is cool with me as well, if it shall be included in MAINTAINERS.txt.

Note from #drupal-contribute: We need to add Berdir as a "Figurer outer of weird-ass shit no one else can." ;)

At least chx, DamZ, c960657, effulgentsia, catch, and sun also goes in there. Maybe this is "Base system" maintainer?

Base system makes sense for the generalists category I think - bootstrap, common.inc, and wtf I don't know where to put this I'll stick it in base system. Moshe, chx and Damien were listed in previous patches, the rest of that list looks OK to me although I'm now concerned about how many places my name is appearing in this file.

Yeah, I guess this is a question. Do we want this file to reflect reality? Or the distorted reality that people's comfort level will allow? And if the latter, what are we actually gaining here?

So, what is the purpose of the MAINTAINERS.txt file, and what does being listed there actually mean? I'd kind of like to know before potentially agreeing to have my name in it and all that :)

I have some idea in my head, and I know this has been discussed ad nauseum elsewhere, but I'm not sure the file serves any purpose if we can't (as part of this patch) put a clear paragraph at the top of the file which explains it - written for an audience of people who might be poking around their Drupal installation. Because if the file doesn't explain what it's for, reorganizing it won't help much. Just the mere fact of having a list somewhere - that by itself could be done more effectively as a handbook page on drupal.org. And the existing file (with no explanation) is probably interpreted by most people as the "credits" (which it isn't).

So, what is the purpose of the MAINTAINERS.txt file...

OD + #18 + #45. In short, who can a developer or core committer turn to to get an in-depth review of an intricate issue?

I also think it's a good place to list what the components of Drupal are and to have the issue queue's "component" options match the ones here, so that someone can choose the appropriate component when filing an issue, and hopefully, at least one of the maintainers is periodically checking the issue queue for issues needing review that are assigned to that component. To that end, I think it would be nice if there exists somewhere an explanation of what each component actually is. I know what a module is, and I know what a theme is. But what's the "render system"? If I have an issue about drupal_get_css() (e.g., #228818: IE: Stylesheets ignored after 31 link/style tags), what component do I assign that to and who can I bug about getting a review? I agree with #39 that it's the render system, but I did not think of that until catch mentioned it, and if the rest of us agree on that, where can that information be captured? If explaining what each system is belongs in a handbook page rather than this file, ok, but we need it somewhere, and this seems like a good issue to figure out that information. Figuring out what each system is might also help maintainer candidates decide if they feel comfortable maintaining that system.

I like webchick's idea in #49 to not require a 1-to-1 map between .inc file and system name, but instead to cluster into as few logical systems as makes sense, but then identify what that system is. What do you all think of this attached file? It doesn't list the maintainers yet, that'll need to be merged from #46, but is the structure getting us closer or farther away from our goals?

I ain't sure such a fine-grained listing is possibile at the moment: for example, parts of the language system are in bootstrap.inc and common.inc and parts of the render system or filter system are in common.inc. If we start listing functions here I am afraid this will become quickly unmaintainable, or perhaps we will need a MAINTAINERS.txt maintainer :)

subscribing...

The main thing I am currently maintaining is the issues filed under component "documentation" in project Drupal.

Someone above mentioned me in the context of trigger, which I do know something about, but haven't contributed at whole lot to (except the Big Trigger Overhaul, which I was somewhat involved in).

I also do know something about search.module (am maintainer of a contrib search-related module, for instance)...

On the other hand, I'm not sure that I want/need to be listed in maintainers.txt at all. :)

Hm. We have some conflicting goals here.

1) For each core module, sun wants it to be possible to look at this file and figure out who its maintainers are (#45).
2) Webchick wants to see some kind of grouping, to keep the file from being unmaintainable due to being too granular (#49).
3) Sun and dww don't like grouping when it leads to them being listed as maintainers for more than they feel comfortable with (#3 and #26).
4) If we list systems in this file, I want clarity around what the system is (#55). But given #54 and #56, perhaps this isn't the file or issue in which to achieve that clarity: we can leave it to some TBD documentation task.

Here's another stab I'd like feedback on. Relative to #46, it pushes closer to webchick's direction, but contradicts #3 and #26, so for those examples, we may need to find some compromise. Relative to #46, it also removes some low-level sub-systems (lock, registry, queue) which I think can just be considered part of the base system. I'm open to more systems being removed (do we need "cron" as its own system?), or the ones I removed re-added (if pwolanin is willing to maintain the lock system, but not the base system, perhaps that's justification enough for considering it its own system). Looking for a pulse check here: @webchick, is this still too granular for you?

Oh, also want to mention that I agree with #54 that an intro paragraph in this file explaining its purpose would be nice.

Comments on the patch in #58:

- Top of file says "branch maintainers". While involved developers might know what that means, it might be better to say "Drupal 7.x maintainers" or something like that, to not exclude new folks from understanding what it means.

- I would be in favor of a brief sentence explaining what "base system" means. Something like

Base system maintainers
-----------------------
The base system is composed of everything not specifically mentioned as a sub-system below.
or
The base system maintainers are people with a wide range of expertise on the whole system.
or
something like that

- I agree with #54, #59 that an intro paragraph at the top would be helpful.

Minor nitpick (repeating myself from #26 it seems):

UPDATE MODULE
See update system

*sigh* ;) This is the confusion *everyone* has. Here's my template response when I reclassify issues from update.module to update system:

I know it's confusing, but "update.module" is for the part of core (added in 6.x) that checks for available updates to your modules and themes. You're talking about update.php, which is the "update system" component...

"update system" is for the DB schema update system (update.php, includes/update.inc).

"update.module" is for the update (status|manager) module (modules/update/*) and probably some of the other parts of the update manager functionality that live in other places (authorize.php, includes/authorize.inc, the FileTransfer classes, the Updater classes, etc).

General comment on this whole process: I think this is useful. Having clarity on these things is important. It's not going to solve all our problems, but it can't hurt. Yes, we have "more critical" tasks to work on before release, but it seems like near the end of the development cycle is as good a time as any to figure out who actually understands the various parts and who really did the work. Having a clear sense of this now, assessing where we're at in terms of resources and expertise, seems like a very important thing to do before development opens on D8. Especially if we're talking DVCS and potentially changing the core development workflow, we should know who's responsible for various parts of core, whose repos we can reasonably trust pulling in changes from, etc.

Oh, and definitely +1 on an intro paragraph. Again, for ourselves as much as for the folks reading the file. ;) But yes, for those folks, too...

Sorry, x-post. (Will no one lend a hand with #218066-16: Prevent cross posting from reverting metadata fields?) ;)

#29: drupal.maintainers.29.patch queued for re-testing.

@sun, I think that's a great explanation. Some of it doesn't require a formal maintainer in order to do - however, I guess one of the points of putting names in a text file that is shipped with every copy of Drupal is to make the people who have signed up to do this feel some guilt and obligation to actually follow through :)

Here's an attempt to distill all this into a single introductory paragraph that could go at the top of the file. Really tough to write, but it's a first draft and at least is something to poke holes into (it doesn't quite apply to the branch maintainers though):

Drupal core is maintained by a community of hundreds of volunteers. To join this group, jump right in (http://drupal.org/contribute); there is no hierarchy or requirement for participation. The people listed in this file, however, have agreed to keep a careful eye on the issue queue for each component of the core system, making sure that contributions in that area don't languish in the queue or go off in an unproductive direction. If you contribute to any of these areas, you'll often see the people below commenting on your ideas, and if, as you contribute, you run into problems or need some guidance on the "big picture" or what to do next, these are some of the best people to seek out.

***

Also, my own quick thoughts (on areas where my name has and has not been mentioned in the comments above):

1. Overlay: Not really dying to do that, for similar reasons as @ksenzee - and the additional reason that I don't think I have quite enough JavaScript experience. It's true I was pretty active in the queue for a little while after the module was committed, but that was more because it needed some help getting going at the beginning, not really intended to be a multi-year commitment :)
2. Shortcut: Yes, I could probably do that. Lukewarm-to-positive feelings about doing so...
3. Install system: I wasn't nominated by anyone above, but I did essentially rewrite the entire installer in a patch committed over the summer, so I know the D7 code very well, and would be interested in maintaining it. It's ideally a two person job though.

This contains the same people as were listed in #46. Before this lands, we should scrub the comments since then to see if changes need to be made to reflect them. I'm +1 for David being listed for "install system". I'm also +1 for jhodgdon being listed for "documentation", though given #57, we may need to do some pleading with her before she agrees to it. #47, #50, and others also need follow-up. I removed "render system" from here for now, because it's not yet sufficiently clear what it is (there's no render.inc), it doesn't exist as a component on the issue queue, and the only identified maintainer for it so far is Moshe, who's also listed for base system. However, I'm definitely +1 for making it a system, adding it as a component choice in the issue queue and adding Frando (as well as Moshe) as a maintainer for it. I also added a "Code generalists" section as a response to #51, though I'm not so sure about it. Feedback on this definitely wanted. I disagree, however, with considering it the same as the base system (#52). I love the intro paragraph suggested in #65, and incorporated it into this patch.

For this one, since a point of contention has been deciding on granularity, I decided to mirror the same granularity already in-use by the "component" drop-down in the issue queue. I think these should stay sync'd. I removed the ones that don't apply to D7. And for ones in this file that aren't in the existing drop-down, I added a @todo.

Comment on patch format: I think in .txt files in Drupal, we normally try to wrap at 80 character lines. Hard to read otherwise, depending on the editor/browser used to read them.

You can put me down as the Topic Coordinator for doc, as well as the component maintainer for documentation. I'm doing that job anyway. :)

Put the usability folks in charge of UI text?

Thanks! This implements #67. Additionally, I added David to the install system (#65) and Frando to the render system (#50).

To summarize, this patch defines components the same way they are defined in the issue queue. There's a few new components added by this patch that aren't in the issue queue, and these have a @todo to add them to the issue queue. What makes these components worth adding is that we have identified a maintainer for them who is someone other than one of the base system maintainers. If some subsystem (authorize? session?) that's not listed here has someone other than a base system maintainer willing to maintain it, I would be in favor of adding it, but I don't think it makes sense to add these as components unless a maintainer is identified for them (at least that's my recommendation for respecting webchick's concern about too much granularity (#32)). But it seems to me that if we have a willing maintainer, we should make it an option in the component drop-down, and if it's an option in the component drop-down, then it should be listed in this file. Also in an attempt to address the too much granularity concern, if component X is one of the choices in the issue queue, but it logically can be seen as a sub-component of some larger group, and it doesn't have any maintainers other than those who maintain the larger group, then I listed: "Maintained by Y maintainers". So that, for example, the 3 base system maintainers aren't also listed in a dozen other places.

Here's a summary of nominations that have not yet been added to the patch, because they seemed tentative:

Install System
Drumm? (#20) 

Language System
Nedjo? (#23)

Seven Theme
seutje? (#20-#22)

Several suggestions: #47

Here's a summary of components without a maintainer (these all have ??? in the file, but here they are in this comment to draw attention to everyone following this issue):

javascript
aggregator.module
blog.module
book.module
color.module
dashboard.module
forum.module
help.module
node.module
overlay.module
  Note: both ksenzee and David didn't want the burden (#14, #65)
php.module
profile.module
search.module
shortcut.module
statistics.module
toolbar.module
tracker.module
translation.module
trigger.module
user.module
markup
css
Seven theme
other

You can potentially put me down for book module since I did the major rewrite for D6 - in fact I thought I was already there.

Go ahead and put me down for statistics.module. I've been working on that module's issue queue for a while.

Also, path system is essentially path.module, so we don't need to add a component for that?

I'm offering myself up here for markup/CSS.

Some of the things I've been seeing in D7 so far have me very concerned and I'm willing do whatever I can to help improve the TX.

I did volunteer for statistics module since I have a plan for making it not suck in D8, so I added myself in.

Thanks! Aside from that:

If you understand the latest patch in #578676: Use queue for cron and its consequences, then you are hereby nominated for Cron system/Queue system maintenance. I'M NOT KIDDING.

update.php as far as I know has no obvious maintainer. Some patches have gone in, but very spread around differenc contributors. This might be connected to the upgrade path from 6-7 being broken for at least half the release cycle.

Node and User, I'd also agree these are unmaintained. Again a few patches have gone in, but no-one has an overview of the whole thing and there's a tonne of crap in there still.

So let's just be honest and document the gaps.

We should not have "Field system" and "Field module". Since it's a module, I'd vote for putting that in modules.

Re: #76: I already volunteered to be a "Queue system" maintainer, but I thought we decided that was pointless to have a separate entry for. I guess you should put chx and me down for cron system, if that's how you think, since we both understand the cron system and how it uses the queue system... ;)

hmm, funny - I didn't see that I got listed for the MAIL subsystem somehow. Given my limited knowledge of the overall mail-related codebase, I don't think that makes sense. I only contributed the patch to the backend routing for D7.

Comments on the file attached to #75 above:

- Why are we listing the D6 branch maintainer in the D7 MAINTAINERS.txt file?
- Before we commit anything, I think it would be good to make sure that every one of the people listed in there understands what they're committing to do and has actually agreed to it (see #79 for instance).
- You can put me down for search.module. Sigh. I do know it pretty well, and I don't see anyone else stepping up.
- The "module maintainers" section is including themes. Section name should be changed accordingly.
- Are the install profiles missing from the file? Probably should be added to the modules section too.

Ugh. I am not sure about becoming the maintainer for search.module. I just took a look at the issue queue and it sure needs some TLC, probably more than I have time for.

Maybe if douggreen doesn't want full responsibility either, we could share it? Not that I know douggreen well/at all, but that might be a good idea.

I haven't really seen Doug Green around since DC Paris, but I agree he'd be a good candidate for a co-maintainer if he's willing.

You can stick me in there for the file system: I'm probably one of about a dozen who currently understands the stream wrapper system. (Unless pwolanin would rather; he knows it better than I.)

mfer, how dare you not tell me about this thread sooner! :-)

I would ask the following question: Does "maintainer" mean "person who wrote it", "person who knows about it", or "person who is closely watching that part of the issue queue?"

In my case, all three apply for me for the DB system. I have two Drupal bookmarks: My Issues, and a saved filter of the four DB components (database, mysql, postgres, sqlite). I may not comment on every issue there, but I read virtually every comment posted in that section, comment on most threads, and try to offer useful input on any thread there even if I am not the one writing it.

That's what each part of core needs. There should be, for any given issue, at least one person besides the core maintainers that has it come up in a custom search they have bookmarked and check regularly. It doesn't matter as much whether that's grouped by module or subsystem or whatever, just that everything has that level of attention. (Which also makes those people the go-to person for the core maintainers, too.)

I just want to make sure that everyone who's volunteering in this thread is on the same page about that. If so, that is amazingly awesome. :-)

I said all three were true in my case, not that they had to be true in all cases. Just that those are all possible interpretations of "maintainer". It sounds like we're on the same page as to what the responsibility of being a "maintainer" is, though. (Authority, well, that's another matter.)

subscribing

I'm ok with the above interpretation. I can "maintain" the Translation module too, if no one else shows up.

Btw, I was wondering: does being listed in MAINTAINERS.TXT mean being a "maintainer" for every Drupal version, or each branch will have its own list? I mean: I wrote most of the current language negotiation system code and I have a good understanding of the 6.x one, but obviously I feel more comfortable with 7.x version.

Re: #91: Like every other file in Drupal core, MAINTAINERS.txt is branched. So, each branch of core has its own copy of this file. Which is good, since the modules can change across versions (e.g. it wouldn't make any sense to have a section about "overlay module" in the D6 copy). So, at this point, we're just trying to get clear on how things stand in D7.

We can consider backporting some of this to D6 when we're done, since many of us will be maintaining the same things in D6, too (except for the new modules in D7, of course).

I'd assume that the current D7 maintainers are going to be the maintainers at least at the start of D8 development. If things change during the life-cycle of D8, and it makes sense to modify the file, we certainly will. If existing maintainers need to step down and/or new folks step up, we'll just keep the file as accurate as possible to reflect the current reality.

I read through the comments here, I'd be happy to be the maintainer for the topic of accessibility. I really like the concept of maintainer as it is explained in #87 / #88.

I have begun (and nearly completed) the process of going through search.module's issue queue, and I do have it bookmarked (a combined search along with the doc component, whose issue queue I've been maintaining for months now)... Given the actually low traffic for issues, the main problem there is that no one has been farming the search issue queue for quite a while.

All that to say: OK, I can take over search.module. I definitely understand it through and through (although I played no part in writing it originally or rewriting for D7 db changes) and am willing to maintain its issue queue.

A) If the first set of system components are being sorted alphabetically, these two need to be reversed:

Batch system
...
Base system
...

B) Why is "Markup" under the "Component maintainers" and not a "Topic coordinator"?

C) Re: color module -- there's a fresh round of effort to make it not suck and be Garland-specific by the folks trying to add the new D7 themes (bartik et al). See #693504: Color.module does not support more than 5 colors and has hard-coded labels for more. Perhaps we should approach some of those people to be listed as color module maintainer(s)? E.g. stBorchert?

D) If we're going to include the proper accents in chx's and scor's names, shouldn't we do the same for Gábor?

E) Really, there's no maintainer for the Seven theme? ;) Didn't we *just* add that? How could it have already fallen into a state of no love? I didn't follow it, so I don't know the history, but can't we find a victim for that one? I understand why no one is willing to stick their neck out and be listed for overlay (I wouldn't want all the hate mail and death threats, either) ;), but Seven seems to be a lower impact job to maintain, no?

p.s. @jhodgdon: yay, thanks for stepping up!

Excellent, thanks sun! Did stBorchert agree for this? ;)

For user and node modules, I propose adding @see Base system. Those modules are effectively base in D7. If folks are not happy with that solution, I volunteer to maintain both. Would be nice to get co-maintainers.

I think we should put Moshe for user and node module. They both still have a lot of stuff in them which is not base IMO, and we have plans to gut as much of the base stuff as possible out of them and into the entity system in D8.

This is looking good to me. Personally I'm happy with my three listings and not volunteering for any more. Have all the people in here been contacted? If not can we take them out of the patch, mark this RTBC, then open individual issues for the gaps?

I'm OK with the definition of maintainer as someone "who is closely watching that part of the issue queue".

@sun: re#15, I believe we coordinate translations with Gerhard. He is more involved with the d.o language teams and I'm feverishly working on localize.drupal.org buildout.

While I certainly wasn't the person who took Tracker 2 to commit status in Drupal 7, I did do most of the original rewrite. I'm probably one of the best-qualified people to evaluate substantial changes to the module. I'm also happy to get pinged about Tracker issues to provide advice and code review. So, by Dries' standard of issue queue awareness and participation, I'd be happy to get listed as a Tracker maintainer.

Of the remaining "???" items, I also have deep knowledge of the menu, node, and user systems and am happy to provide similar advice and reviews on them.

I don't think we should refer to the "Menu module" in the maintainers list because the terrifying stuff is all in menu.inc. Rather, it should be the "Menu system," which includes the module that's all-too-closely-coupled with menu.inc.

I've been thinking about picking up Seven and markup & css in general, but looks like jacine already picked up markup and css got removed somewhere (even though there's still a drupal.css component with quite some issues, more than markup even)

I'll bookmark those 3, start sifting trough and keep an eye on them

Of the unconfirmed, these are the ones that afaik volunteered somewhat recently, so could be moved back to 'confirmed':

- Andrew Morton 'drewish' http://drupal.org/user/34869
- Barry Jaspan 'bjaspan' http://drupal.org/user/46413
- Benjamin Doherty 'bangpound' http://drupal.org/user/100456
- Damien Tournoud 'DamZ' http://drupal.org/user/22211
- Jimmy Berry 'boombatower' http://drupal.org/user/214218
- John Wilkins 'JohnAlbin' http://drupal.org/user/32095
- Josh Waihi 'fiasco' http://drupal.org/user/188162
- Roy Scholten 'yoroy' http://drupal.org/user/41502
- Stéphane Corlosquet 'scor' http://drupal.org/user/52142

And these I'm pretty sure are still going:
- Addison Berry 'add1sun' http://drupal.org/user/65088
- Earl Miles 'merlinofchaos' http://drupal.org/user/26979
- Gerhard Killesreiter 'killes' http://drupal.org/user/83
- Heine Deelstra 'Heine' http://drupal.org/user/17943
- Jeff Eaton 'eaton' http://drupal.org/user/16496
- John VanDyk 'jvandyk' http://drupal.org/user/2375
- John Wilkins 'JohnAlbin' http://drupal.org/user/32095
- Josh Waihi 'fiasco' http://drupal.org/user/188162
- Joon Park 'dvessel' http://drupal.org/user/56782
- Khalid Baheyeldin 'kbahey' http://drupal.org/user/4063
- Nathan Haug 'quicksketch' http://drupal.org/user/35821
- Roy Scholten 'yoroy' http://drupal.org/user/41502
- Stefan Nagtegaal 'steef' http://drupal.org/user/612
- Stéphane Corlosquet 'scor' http://drupal.org/user/52142

Which leaves these who may not have been asked yet:
- Christian Schmidt 'c960657' http://drupal.org/user/216078
- Stefan Borchert 'stBorchert' http://drupal.org/user/36942
- Wolfgang Ziegler 'fago' http://drupal.org/user/16747
- Doug Green 'douggreen' http://drupal.org/user/29191

I'd suggest adding those last four, and/or removing/replacing anyone, gets done in individual issues so no one gets lumped in or removed without even being asked. We can open followups before commit so they don't get lost. Apart from that, what holds this back from RTBC?

seutje:

I've been thinking about picking up Seven and markup & css in general, but looks like jacine already picked up markup and css got removed somewhere (even though there's still a drupal.css component with quite some issues, more than markup even)

Yay!
1. The more people listed, as long as they meet the criteria, the better, as far as I'm concerned, so I see no reason to refrain from adding seutje just because Jacine is listed already.
2. Clarity around the css question might be nice. Seems like theme css is part of the theme. What about module css? Part of the module, or part of the "markup" topic, or does it need a separate "css" topic? And what about css in the "misc" folder?

Dries:

I'm OK with the definition of maintainer as someone "who is closely watching that part of the issue queue".

Yay!
But my interpretation of #61 and other discussion about this is that the definition is a little tighter than this. Someone who isn't just watching the issue queue, but also has the expertise and confidence to either mark an issue RTBC or provide feedback as to what still needs to be done. Not for every issue: I agree in the buddy system where a newer maintainer may want to check-in with a more senior maintainer on some issues, and some issues may require discussion among several co-maintainers or maintainers from other components, or require more community discussion in general. And I also don't think that marking something RTBC is the exclusive privilege of the maintainers, but is something anyone can do. But I do think that part of what it means to be a maintainer is that you will often be marking things RTBC, and that the branch maintainers will trust that if you did so that you did so only after a careful review.

If it's ok with Eaton, I'd also like to be listed for the token system. It's small but I know it backwards and forwards.

Agreed with effulgentisa regarding what being a maintainer means. At minimum, it should mean:

1) Know the system really really well.
2) Is trusted by core maintainers as a domain expert in that area for how it works and what changes to it would mean. (Yes, that means that their RTBC or +1 "means more" than someone else's.)
3) Is actively monitoring issues for that system to know what is going on and can give expert input regularly.

I'm ok with adding me to the forms system. :)

subscribe

Thanks effulgentsia for pointing me to this issue. Per #61 and #88, I'm confirming I'm happy to be listed as maintainer of the rdf module.

What's the ordering when we have co-maintainers?

Render system
- Moshe Weitzman 'moshe weitzman' <http://drupal.org/user/23>
- Alex Bronstein 'effulgentsia' <http://drupal.org/user/78040>
- Franz Heinzmann 'Frando' <http://drupal.org/user/21850>

Shouldn't it be in alphabetical order?

Shouldn't it be orderd by color preference? But yhea it might be weird to go with alphabetical as it would mean that Dries is below Angie, and visa versa for other categories. The quantifiers sun proposes are better, however that is a bit unmaintainble probably.

I'm in for merging them. Cause most of the latest patches were combo javascript/html/css patches.
Merging the core themes is easier to find cross theme issues.

Double + for everything Sun says

+1 for sun being co-maintainer of the markup component, or whatever we start calling it.

On balance, I'm in favor of merging "markup", "drupal.css", "javascript", "garland", "seven", and "stark" into a single component ("front-end"?). I know several markup/CSS experts who are not JavaScript experts, and vice versa, but I think that's ok since those people can focus on the issues that they feel comfortable with, and skip over the ones they don't. Perhaps some more feedback from people who've been active on the "markup" and "javascript" queues would be helpful though.

One benefit I see from removing a "javascript" component is that we can then add an "ajax system" component, which we already have in #105, but not on the issue queue yet, and not have it be as confusing. Unfortunately, lots of people on the web use AJAX as a synonym for JavaScript, even though these are not synonymous.

I'm also concerned that at the rate we're going on this issue, we'll be at 7.0-rc2 by the time we commit this patch. But I think committing this patch, and adjusting the issue queue components accordingly will help us move through the issue queue more productively throughout the betas. Does anyone else share this opinion and have ideas for what to do about that?

Related to revamping the issue queue, I would discourage any ideas, if they exist, to create an accessibility component. The reasoning for this is that accessibility issues are related explicitly to other components, and often require contribution from developers familiar with the affected components to resolve. In my opinion, if there is an accessibility issue with Seven, for example, that issue should always be filed against Seven, and tagged with accessibility, not the other way around.

Yes we used to have a usability component but removed it in favour of tags, much the same arguments apply to accessibility.

'Front-end' sounds like a good idea, somewhat analogous to 'base system' in that it's hard to divide up meaningfully.

I think to get the patch in sooner rather than later, we need to remove people who aren't confirmed in this issue, then try to add them in followups, i'm not clear on what the current status is though.

subscribing.

Yay, good to see you here, rfay. I nominate rfay for "ajax system" co-maintainer. He's been already doing it for months. Though one challenge is that it's not one of the component choices yet. So, those issues are scattered across "javascript" and "forms" and other components. I've been starting to use the "Ajax" tag to organize them, and we can always just search on "ajax", since many ajax issues use "ajax" in their issue title. I've refrained from opening an issue to add an "ajax system" component to the issue queue, partly waiting for this issue to make more progress, and especially in light of #117/#119: perhaps that should be resolved first.

I officially apply as maintainer of the Translation module. Being the co-maintainer of the contrib Translation module, which will eventually replace the core version, this is a pretty obvious solution as I would keep an eye on the Translation queue anyway. Moreover sooner or later the translatable fields issues will mostly concern it.

OpenID is a personal interest of mine (I don't use it at work), and interests tend to change over time, so I wont make any long term promises. For the time being I don't mind keeping an eye on the issue queue for OpenID issues or providing opinion on suggested changes. I would probably do that even without being listed in the file (Edit: I just realized that I haven't been doing this regularly, so being mentioned as maintainer would probably help on that habit). So count me in.

Given the dynamic nature of this, it may be better to store the list on the website rather than in CVS. The list is not really that interesting to people who download Drupal, at least not more than so much other developer-oriented information that is only available on d.o. This would also allow for a more elaborate description of each person's expertise and interest.

I think it would be useful to list as many maintainers as reasonably possible in each area, possibly with a distinction between lead maintainers and followers. This makes it easier to adjust when a person leaves the project, and it may make the followers feel more committed to certain parts of the code.

One more try: #706540: Register all core modules/APIs on drupal.org

We could list maintainers on the project pages.

I'm fine for maintaining the image system. I'd prefer not to be the maintainer for poll.module though. ;-)

Please add me as a token system maintainer.

Unless there's an objection, I'm willing to be in there as AJAX system comaintainer.

Sorry, I must confess I did not really follow this thread lately.
If it's about confirmation, I agree for Batch API and Field UI maintenance. Comment.module feels a little undeserved.

If you want people in MAINTAINERS.txt CONTACT AND ASK them.

+++ MAINTAINERS.txt	18 Mar 2010 12:39:29 -0000
@@ -1,83 +1,283 @@
+Field module
+- Yves Chedemois 'yched' <http://drupal.org/user/39567>
+- Barry Jaspan 'bjaspan' <http://drupal.org/user/46413>

I'd postpone the "field system" > "field module" change to a followup issue: this currently introduces (yet another) inconsistency with the issue queue.

Powered by Dreditor.

Final changes (mostly unconfirmed or inactive, feel free to correct):

- Not confirmed: Removed quicksketch from File system and File module.
- Not confirmed: Removed pwolanin and DamZ from Lock system. Lock system is empty.
- Not confirmed: Removed eaton from Token system. Token system is empty.
- Not confirmed: Removed stBorchert from Color module. Color module is empty.
- Not confirmed: Removed Heine from OpenID module.
- Not confirmed: Removed douggreen from Search module.
- Not confirmed: Removed jvandyk from Trigger module. Trigger module is empty.
- Not confirmed: Removed JohnAlbin from Stark theme. Stark theme is empty.
- Not confirmed: Removed yched from Comment module.
- Not confirmed: Removed yched from Batch system and Field UI module. Wonky, but yeah.

I'd recommend asking these people first, over having maintainerless modules.

Yes I agree with Heine, removing people should be in a separate issue and proceed by contacting them, not collateral damage in this one.

I'd recommend asking these people first, over having maintainerless modules.

@Heine: are you ok with maintaining the OpenID module? :)

@plach, yes
(Christian (c9..?), DamZ and I are already the defacto maintainers).

We need to fix the coding standards area.

It is not a job for one person. It needs be a committee including people who have experience with other projects and can work with the entire Drupal community, where everyone will be an objective voice (considering all opinions carefully, researching what other projects are doing, etc.),

I would say that the maintainers of the Coder module would be the best choice. All of them have been advocates for testable standards and for improving the standards of the current code base (core and contrib). If they're willing...

I tend to agree with jhodgdon on the coding standards. That's such a touchy subject, and it's not an area where one person's voice should be privileged, IMO. To be honest, I'd like to see that section removed from MAINTAINERS.txt entirely. At the very least, we should remove it here and discuss it in a separate issue. This one is unwieldy enough.

In other news, I am giving in and agreeing to maintain the red-headed stepchild that is overlay module. I am sure I will regret it. But you can add me to the list there.

@ksenzee, @jhodgdon, I'm don't think that the maintainership and the decisionmaking on coding standards are the same thing. IMO a maintainer or two could make sure that the documents we have reflect the community's view on coding standards. That's a bit of privilege about potential commits, but it doesn't invest a *lot* of power. That person(s) would need to work from a consensus of a possible committee or list of interested persons. But based on my reading of this issue, maintainership is not the same a owning the whole thought process. Every API has interested parties who are necessarily consulted in the course of a significant change, and that includes people who are not on the maintainers list. Coding standards are the same.

Given the time I spend on the various issue queues, not sure why you want me in the "unconfirmed" column.

rfay #144: If maintaining coding standards is just a matter of making sure that the coding standards docs [and I would add, the Coder module] are in line with community consensus., then maybe it is just part of documentation and doesn't need a separate maintainer?

@jhodgdon, I think a maintainer is a good idea. Just not that the maintainer is "god", having the ability to make single-handed decisions about what the standards are. That's not what maintainership is about, IMO.

Re: #148: "Again, this list is not about credits, but about active and current maintainers. Maintainers of contributed projects are changing all over the time."

Sorry to step in again so late in the game with this, but if the above is true (which it is), then the whole approach of a text file that's tagged and released with the code is wrong. If all problems in computing can be solved by caching or another level of indirection, in this case, we need the level of indirection. The MAINTAINERS.txt file should be something like:

// $Id$

Drupal core is maintained by the community.  To participate, see:

  http://drupal.org/contribute 

Branch maintainers
------------------

Drupal
- Dries Buytaert 'dries' <http://drupal.org/user/1>
- Angela Byron 'webchick' <http://drupal.org/user/24967>

Other maintainers
-----------------

Certain people have agreed to do more quality assurance work for
particular areas of Drupal. For the current list, please see:

  http://drupal.org/drupal-core-maintainers/7

And then these lists should move into the handbook where they can actually be edited in real time as needed. Trying to keep this list accurate as a text file in CVS and shipped with core is a disaster. Plus, once 7.0 is out, lots of people will stick with that copy of MAINTAINERS.txt for a long time, even if active maintainers change in the meanwhile. Hence, we need a level of indirection. The text file should just be a pointer to the real list. That way, the text file never needs to change for any given branch.

p.s. The CHANGELOG.txt doesn't have this problem, and is useful if you're offline. However, the primary point of MAINTAINERS.txt is to tell you who to interact with when dealing with issues or IRC discussions, so you're by definition online at that point, so keeping the list on d.o is a feature, not a bug.

I think @dww is generally correct - we really do want to figure out how to distinguish this from a "credits" file, and haven't done that yet. I sort of asked that question above and tried to write an introductory paragraph for the file (aimed at the person browsing around their Drupal installation), but it came out too wordy and more suited for drupal.org than the file itself. So it was rightfully shortened, but the problem remains.

However, it's also the case that (a) maybe putting names in this file helps humanize Drupal a bit and give some sense of the size of the community? - and (b) the file already contains a list of names now - we don't necessarily have to remove them in order to make progress in this issue, just improve them. And at 150 comments, it would be great to get an initial commit here that at least makes this file better than it currently is :)

With that in mind:

Drupal core is maintained by the community.  To participate, jump to

  http://drupal.org/contribute

This should be "go to" rather than "jump to".

The people listed here agreed to do more quality assurance work for particular
areas of Drupal.  All of them are subject to change.

I think it would sound better to say "have agreed to" rather than just "agreed to", although I can't really explain why :)

Branch maintainers
------------------

Drupal
- Dries Buytaert 'dries' <http://drupal.org/user/1>
- Angela Byron 'webchick' <http://drupal.org/user/24967>

Something seems a little odd here - Drupal is a branch? Shouldn't this section somehow identify Dries as the project lead and webchick as the Drupal 7 branch maintainer?

Overlay module
- ?

As per #143, @ksenzee should be added here - quick, before she changes her mind!! :)

Opened #746920: [meta] Complete + clean up MAINTAINERS.txt and drupal.org components for those who remain to be asked / didn't find this issue and hence aren't in this version of the file.

Handbook page sounds more maintainable, but I agree with sun about the under pressure bit. Either way that's a separate issue.

We are going to expect a lot from our MAINTAINERS. I think being listed in the shipping software is a lot of the "reward" for the work they have done and will do in the future. So, I like names in the text file.

Yeah, but the point is that having a 7.0, 7.1, 7.2, 6.15, etc. version of MAINTAINERS.txt doesn't really make sense, for the modules and components.

I also personally don't think it's a reward to have my name in a file that ships with Drupal. If that's the purpose, then please remove me. I don't need people thinking they should use my d.o contact form as a support channel (which they will).

I just saw this patch thanks to sun's tweet yesterday. I'm cool with being in the MAINTAINERS.txt file, but it can wait for the follow-up.

I don't think it makes any sense to change MAINTAINERS.txt for point release - we're getting stricter and stricter on backporting bug fixes from the development version, so all active 'maintenance' really happens there - if people take over or drop out, that'll be reflected in the Drupal 8 version of the file.

Thanks for all the great work on this, folks. Committed to HEAD.

It'll be interesting to see what impact (if any) this change has in getting those ?s more attention.

Some follow-ups:
#766862: Add component "ajax system" to Drupal project
#766874: Please add "render system" as a "component" for the Drupal project issue queue

Other follow-ups mentioned in #148 seem like they may need discussion or other prep work, so not sure where to file those, but if anyone does open issues for them, please link to them from here. Thanks.