Or: how to improve the process of becoming a co-maintainer?
I’ve had more than a few projects where we used a contrib module and found a bug. We then searched the issue queue of that module to find out we were not the only one with that bug. And if we were lucky, there was also a patch that fixes the bug, so we could patch the module and carry on. But we need to make sure we document this patch to not override it when we update the module. As a Drupal developer you really want to use full released and unpatched modules.
It often happens that the maintainer of the module is too busy with other stuff and that an issue is left untouched for months. Or even worse, someone posted a patch and the maintainer doesn’t respond at all. Not even an “I’ll test when I have time”. Quite frustrating, if you ask me.
During the Drupal Process Days (CXO days) last week in Amsterdam we talked about this process and how to improve this. Some suggestions were discussed:
- There already is a procedure to become co-maintainer of a module, which few people are aware of. However, this process involves a lot of steps and takes al least 2 weeks time. And with >1000 open issues in the webmasters queue, probably a lot longer. One of us tried to walk that path, without luck.
- Implement an automated process where someone can become co-maintainer by pushing a button on the project page (only for those with GIT access). The maintainer can have a week to cancel the request, with an explanation on why not.
- As a maintainer, stimulate those who contribute patches to become co-maintainer. Some maintainers don’t want co-maintainers; whether it’s the loss of control or credits, I don’t know. But I think it’s a missed opportunity; getting someone on board doesn’t only help you fix this one bug, but he/she might help you to answer other issues as well. Take this example in one of my modules, where madmatter23 contributed a patch. I’ve asked him to jump in as co-maintainer and he did. After this bug, he solved several more issues and is still maintaining the module. Cool!
What are your ideas? How can we improve this process? Please let me know in the comments.
edit: changed the title from 'lazy maintainers' to 'slow maintainers'
Comments
In general most maintainers
In general most maintainers are really happy if people stand up and help. I like your suggestion 1 and 3
but
I'm sorry but this can't be enoughst. All you know that people have their dayjobs, so do you, so getting co-maintainership should ALWAYS invole positive feedback of the module maintainer. I would bet that you could, without problems, get 50% of all modules with that.
Track forks
The 2 week delay in the procedure is a real b*tch and 90% of the time, you just don't have that time.
In this scenario, when a maintainer is unreachable/unwilling, another option would be if you could easily fork projects, and d.o. would track these versions (a bit like github). Then, based on the activity/number of downloads a fork could become the new recommended version, or - if the original maintainer finally wakes up - be merged alltogether.
I admit this does potentially render a lot of duplicate code, but it is kinda the way it works right now, with the main difference that d.o would have a mechanism to track/support forks which would help keep everything organised.
Noone prevents you from
Idea
Actually. This sounds like an idea. The project page should list those forks. Just like Github displays a "Network" tab on its' project page listing forks and merges. Currently, it doesn't.
In fact, d.o should just take a queue from Github and take it a step further. Why not just forking a project, patching it and sending a pull request to the original maintainer who merges it back into the original repository?
I think we can take it a lot further then that. The point is that d.o doesn't fully exploit the distributed nature of Git, causing projects to fall easily into maintainance limbo the moment the original maintainer abandons the project without a successor.
Github model
Completely agree. The model of forks and pull request used on Github doesn't delay anyone's work, yet allows full collaboration. The d.o models is still centralized around the original repo. Hence the problem with unmaintained modules. The Github model still allows for co-maintainership as we have, so it could be a good solution to the problem.
Eventually
As I understand Phase 3 of the git migration, it will work like Github in this respect eventually. I don't know what the status of this is, though, or even where the issue queue for the project is located.
I don't understand why this
I don't understand why this can't be done with patches until such time as you get approval to become a co-maintainer.
While there's nothing stopping you from 'forking' and maintaining a sandbox project with up to date code, there's also nothing preventing you from using patches posted to the issue queue.
Patching without applying them is useless
I've have had several cases where a patch was posted but completely ignored by the current maintainer. The problem with using patches is as I described in my post; you have to keep track of them while maintaining the site and you have to go live with patched modules. I always try to overcome this, and if it would be possible to get an obvious bug fixed in the module before going live - I'd prefer that.
Ignored is somehow the same
Ignored is somehow the same kind of thinking as "lazy".
Most time the maintainer just don't have the time to do the work to get the patch in. You know you have to care that things still work, even with the patch.
If you really want something in, write tests for your patch :)
Not "lazy"
I'd like to point out that module developers can *rarely* be described as "lazy", a better term would be "busy", "overloaded" or "overwhelmed", possibly even "burnt out". But "lazy"?
Just to clarify: it doesn't take two weeks to become co-maintainer, that can be done instantly by one of the current module maintainers. What does take two weeks is to be made co-maintainer or maintainer if the current maintainer is unresponsive to your requests.
The existing process for abandoned / unresponsive maintainers works fairly well with only a handful of project ownership change requests open. Yes, officially it takes two weeks, and that is to allow for a response from the existing maintainer after you've tried to contact the maintainer directly; it also allows for delays for the maintainer for those occasions when something out of their power has kept them away, e.g. having a child, being in hospital, vacation, etc. Two weeks may seem like forever when you're trying to fix a patch for a client right now, but in the scheme of things it's not a big deal when you can temporarily patch your local install while working on the process.
As for your idea of forcefully taking over a project, that is categorically unfair for developers that are too busy to deal with your one issue right this very minute but who have every intention of dealing with it soon.
Not meant to be offensive
Hi Damien,
thanks for you valuable opinion. To clarify; I didn't really meant that maintainers are lazy, but I just chose a title that would open up a discussion. I'm looking for ways to make sure people who want to help maintainers who are too busy to answer an issue in weeks, can go on and help.
I've changed the title to busy.
+1
How can anyone call maintainers lazy, that is offensive.
I changed it to busy
As said above, I already changed it to busy. Most maintainers are indeed very busy and just not able to respond to all those issues. But some maintainers only share their code and hardly do any maintenance. Which is better than not sharing, but the lack of support can be troublesome to some. That's why I started this discussion about implementing a better process.
And whether you find the orginal title offensive or not: at least it started a good discussion ;)
I think you should take a few
I think you should take a few steps back and look at the problem from there.
Ask yourself: Is Drupal, the community, a good Project-manager. Can a loosely organised band of web*developers* ever be good project maintainers, -mangers and the developers of the infrastructure?
I've said it on numerous occasions and I think I can say it here again: I think the real problem lies within the fact that we are trying too hard to manage all the projects ourselves. I think we can safely assume we have failed. Drupal.org has a horrible issue-queue management. A terribly difficult release-procedure and a gigantic time- and energy consuming procedure to get projects approved. And why?
The only real answer you will ever get is "that it is really convenient that all projects are found in a central place". I call that a silly argument. Have the community build a great module-search-engine. A fantastic ranking algorithm and be done with it. Such an algorithm or search-engine could and should include activity of a project when including it in the results.
Leave hosting, applications, PM, issuetracking, etc. to the developers themselves. To the Githubs, Bitbuckets, Unfuddles and the likes. And lets focus on what we do best: develop sites.
It will free a lot of energy for important stuff, but most importantly, it will let us, maintainers, maintain our projects in our preferred environment.
Take myself. I have most of my projects on github, including my Drupal-ones. For me, that is my familiar environment. I can deal with pull-requests, get my issues, tickets etc in a central environment and have a full-featured project environment for that. But it takes me a lot of effort and time to update my d.o code, follow up on patches there. To not forget to push to Drupals offbeat branched-repo and most of all, to make sure that any feedback posted "over there"(on d.o) gets migrated to over here (github, where I actually maintain and manage my projects).
Long story short: just give it up. Drupal is not a good project-hoster, despite all the fantastic people working their ass of for that. Despite all the free time those people spend on it. Somehow Drupals project envronment is maintainer-unfriendly, compared to environments as Github, Unfuddle, Bitbucket and even sourceforge. I am sure people will disagree; but that is my point: let maintainers choose the environment they prefer. That best fits in their workflow.
Is there anything preventing
Is there anything preventing you from just hosting your projects on Github or elsewhere? I'm not aware of any conditions in the license or anything that would require publicly-released modules to be available on d.o—and there are plenty of modules and themes that are only available on Github. There are certainly aspects of the d.o project hosting that could stand to be improved, but the "just give it up" attitute won't fix anything.
Shifts the workload to the users
Instead of developers having to learn the release system and fight with the lackluster tools on d.org users will have to learn 5, 10, 20 different systems to report a bug.
Have you ever tried to report a bug on a piece of linux software? My experience has been it takes at least 20 minutes to even find where to post it, and then you're faced with a piece of software you've never used and a system you likely don't have credentials for.
If the end goal is better software I think more and higher quality bug reports are the most important ingredient to getting there, otherwise the developer sits off in their silo thinking "I must have done a pretty good job, no bugs reported since I posted this code!"
Maintaining a fairly popular
Maintaining a fairly popular module is hard. At the moment, I'm looking for comaintainers, but the people who are applying generally email with "Hi I'm completely new to Drupal, can you give me the keys to the kingdom, by the way what is git?" I usually encourage them to work through issues in the queue first, but no one does.
It's a two way street.
Yup
This is exactly why I don't like the sound of suggestion #2 in the original post: it would be too easy for newbs to abuse. We definitely want to get more people involved in contributing, but there first experience with it should not be a co-maintainership denial because they want to add an inappropriate or site-specific feature to some module. For exactly that reason, I don't think it would be fair to existing maintainers to put it on them to deny these requests.
What if we copy the core workflow
I agree that it would not be good to give inexperienced developers write access to the git repository. And there already is a good process for new users to achieve git write access where they learn about coding standards and version numbering.
But suppose we have the following flow:
Now we can ask Dries or Angie to commit the issue, but I think they have enough work already on their shoulders. So we implement an automated process to become co-maintainer - only usable by developers who already have contrib projects and know how to write proper code. Would this work?
Probably
If this automated process was only available to users who have full project access: yes, I would agree that it would be a great solution.
find a co-maintainer
As someone who has co
As someone who has co-maintained other people's projects, and founded projects and taken on co-maintainers, my comment is that Drupal.org simply isn't set up to handle co-maintainers.
It is very easy to forget that you are the co-maintainer of a project, and the facilities available to a co-maintainer are not even close to what the maintainer has.
In projects I maintain that have co-maintainers, the role of the co-maintainer is usually to contribute one or two patches, for something they specifically care about and then you never hear from them again.
For projects that I have been added as co-maintainer where the maintainer has left the building, there is no way for people creating issues in the queue to alert me to the presence of those issues. I have had to resort to creating a sandbox queue for myself and linking to it from the project page of issues I "co-maintain" all by myself to give people a way to notify me.
This is just one of the many shortcomings of the Drupal.org issue queue system, and why I may have to just simply neglect the issues of about 20 projects. The system just does not provide enough functionality for me to properly manage issues, and just makes life difficult.