There are a few people in some of the revisions of #621618: Revamp MAINTAINERS.txt who didn't make it into the final patch, mainly because they didn't confirm themselves as wanting to be listed. Suggest we do this in individual issues rather than one big patch, so it doesn't drag on like the last one, but this'll do as a placeholder.

Comments

sun’s picture

StatusFileSize
new2 KB

Last known diff.

sun’s picture

Also, copying the list of potential follow-up issues from #621618-148: Revamp MAINTAINERS.txt:

Maintainers:
- Discussion about removal or replacement of inactive maintainers.
- Adding the suggested/nominated, but yet unconfirmed people.
- Add some more people to base system? - or - Also list generalists?

Handbooks:
- Overview of components.
- Purpose of MAINTAINERS.txt and explanation of what it means to be listed in MAINTAINERS.txt.

Components:
- Merge "Field system" into "Field module" component on d.o.
- Merge "Node system" into "Node module" component on d.o.
- Merge "Update system" into "Install system"?
- Add AJAX system component to d.o.
- Remove drupal.css component on d.o.
- Merge JavaScript and Markup components, and rename to "Front-end" or "Theming" or similar?
- Merge "$theme_name theme" components?
- Add a Coding standards component? jhodgdon + me?
- Add a Cache system component?

plach’s picture

johnalbin’s picture

subscribe.

sun’s picture

Title: Meta issue - fill in MAINTAINERS.txt gaps » [meta] Complete + clean up MAINTAINERS.txt and drupal.org components

I analyzed the entire #621618: Revamp MAINTAINERS.txt thread once more and revised the list in #2. Also, better title.

effulgentsia’s picture

- Add AJAX system component to d.o.

Done. Yay!

Adding "render system" component to d.o. needs more input: #766874: Please add "render system" as a "component" for the Drupal project issue queue

- Merge JavaScript and Markup components, and rename to "Front-end" or "Theming" or similar?
- Merge "$theme_name theme" components?

What's the latest thinking on this? A single "front-end" component that includes "javascript", "markup", and all core themes? Or two components: "unthemed front-end" + "core themes" (names to be improved)?

sun’s picture

  1. I'd highly prefer to discuss individual changes in this meta issue first, and only spin-off actual change requests for agreed-on stuff afterwards. Easier to follow for everyone, IMO.
  2. render system: I agree that we have a render system now, and most of the theme system is part of it. But effectively, I'd associate different people as being experts for each one, which also means that people might like to have different components to assign. Not sure what our long-term goals regarding render and theme systems is. Merging theme into render system would make sense if we think that the render system will take over more and more of the theme system (and it likely will, when considering alternative data types like XML, JSON, etc).
  3. Discussed that idea with Jacine and we came to the conclusion that we (Jacine and me) don't really care for core themes. We care for "themer experience" and proper HTML/CSS/JS, but we only touch the core themes because we have to. Therefore, merging markup + javascript + drupal.css into a single new component would make sense. No idea of a proper component name though.

    Whether core themes could or should be merged, I can't tell. The respective maintainers should speak up.

damien tournoud’s picture

Also, if you want to *rename* an existing component, or *merge* two components, please give us an head start so that we can pass the correct query to reassign all the issues (the Project Issue module doesn't do that automatically).

jhodgdon’s picture

Status: Active » Reviewed & tested by the community
StatusFileSize
new530 bytes

I have decided that I would like my name removed as maintainer of the core Search module. The reason is that I don't think there is any real meaning attached to being listed as a module/core system maintainer.

And just to be clear:
- I plan to continue to do what I have been doing: creating and reviewing search.module patches, monitoring/triaging the search.module issue queue, helping to plan for D8, etc.
- I'm still willing to be listed as the API doc coordinator in maintainers.txt, and I plan to continue that work too: creating and reviewing doc patches, monitoring the doc issue queue, working on standards, keeping an eye on the API module, etc.
- Nothing should change except that I don't want my name on that line of the file as one of the "official" maintainers of search.module.

Here's a patch. And yes, I've thought this through, so please commit it. Thanks. Taking the liberty of marking it RTBC.

dries’s picture

Status: Reviewed & tested by the community » Fixed

OK. Committed to CVS HEAD.

jhodgdon’s picture

Status: Fixed » Active

Probably should set this issue back to active for the above questions...

Everett Zufelt’s picture

fgm’s picture

Would you mind adding me as the maintainer for XML-RPC ?

I think I might be the one most interested in this subsystem. (I fixed the multicall implementation, added hook_xmlrpc_alter, and an extension to examples/xmlrpc_example).

jhodgdon’s picture

fgm: File a separate issue with a patch, like Everett just did for Accessibility, and link it here.

fgm’s picture

For the record, issue was #895358: Add an XML-RPC maintainer

sun’s picture

One of the @todo items in above list: #898538: Remove markup, CSS and JavaScript components

jacine’s picture

I just wrote this over here #898538-7: Remove markup, CSS and JavaScript components, but it's relevant to this issue, so I'll repost:

I agree drupal.css needs to be removed, as we are currently maintaining markup and CSS under the "markup" component. This is also problematic because it doesn't properly describe what we are actually working on. Markup is not CSS. We also deal with JavaScript issues, so what I really think we need is a "Front end" component or maybe even just a tag to replace both of these.

The advantage of using a tag over a component is to keep issues properly organized with the module they affect. For example, if we have a markup issue that means making changes to the comment.module file, the maintainer of the comment module doesn't get a chance to stay in the loop and finds out about the change after it has been committed.

Regarding core theme components, I don't think they should be merged. From the work I've done on Bartik, I'd guess that 9/10 times their issues do not affect one another. Different designs and different code mean different and totally unrelated bugs. When a specific issue affects all themes, it's likely something that we (markup/css maintainers) should be dealing deal with fixing at the source of the problem.

Jeff Burnz’s picture

I would like to be considered for the maintainers role for Seven, and as co-maintainer for Bartik.

#927036: Maintainers role for Seven, Co-maintainer for Bartik

johnalbin’s picture

Patch to add me to theme system, block module and Garland. #975168: Add JohnAlbin to MAINTAINERS.txt

I contemplated being added to Bartik given the amount of work I did for it, but I'm happy with Jeff's work maintaining it since it was included with core.

arianek’s picture

Patch to add me to Docs (and remove Addi, now that she's stepped down) #975206: Update Documentation maintainers Jennifer is already on there (we're sharing the lead role officially as of two days ago). ;)

jhodgdon’s picture

Status: Active » Fixed

D7 has shipped, this is done.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.