What's your idea?
Lets put a good looking badge on project pages who's maintainers are doing a stellar job with release management. They need to be given the cred they deserve and users will be able to find their projects more easily too.
The #D7CX pledge, http://cyrve.com/d7cx, for modules to be ready for Drupal 7 was quite a success in the sense that a lot of contrib maintainers signed up to it. Unfortunately only a fraction of those projects where ready when Drupal 7 launched, despite the long delay.
This idea can also be seen as logical addition to the Drupal Coding Standards (https://drupal.org/coding-standards).
A problem many site owners faces is to often be forced to use dev versions. This because bug fixes and improvements often take a lot of time to be rolled in a new full release. In worst case the only choice is a patched dev-version. Many projects also get stuck in alpha or beta. Even in RC we see a lot of contrib projects not only stuck but also new functionality added between release candidates.
This leads to a lot of headache for sitebuilders and admins as they need to invest a lot of time keeping track of the latest dev commits being added and if they should update the site or not.
They also have to invest a lot of time to learn the individual release management systems different projects owners use.
In this day of age when it is not uncommon that a Drupal based site has 100 or more contrib project, I'm sure you can see the overhead here.
In contrast Drupal Core has a very detailed and rigid set of rules and guidelines, https://drupal.org/core/release-cycle, for how this is handled. Both for a new major releases and point releases.
A simplified opt-in release management scheme for contrib projects would provide a great guideline for both project maintainers and user to mitigate this. It would give project maintainers a best practice workflow to follow, while at the same time make it much easier for users to know which projects that has the ambition to follow the scheme.
Included in this scheme would be recommendations/guides for how and when bugs should trigger a new stable release. How, and when, new features should be going through alpha to beta to RC and eventually to a new stable release.
- Project owners opting in to this scheme will be able to display a badge on their project pages
- The projects search will have a filter option to only include projects that have opted in to the scheme
What are the benefits?
- It will help educate project maintainers and contributors about best practice release management
- It will make it much easier for any user to quickly know what projects have a proper release management
- In the long run it will help to raise the quality of code and functionality
...and:
- It will make all those amazing project maintainers that already does a stellar job stand out and get the credit they so well deserve.
What are the risks?
The main risk is the same as with the #D7CX pledge in that project owners opt-in but not follow through. This can be mitigated by the possibility for d.o. webmasters to demote projects from the scheme.
How can we measure the impact of this idea? (metrics)
The number of project opting in and the impact it will have on code quality and improved maintainability of both contrib projects and sites.
Who directly benefits from / will use this improvement? (target audiences)
Everyone
Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)
The scheme should be a simplified version of https://drupal.org/core/release-cycle. Then it will also help prepare developers for core contribution too.
Comments
Disagree on the premise
Just a note... The start of this post says that D7CX was a success. I disagree: yes, many people signed up for it, but very few actually followed through by making a release of their project when D7 was out. Some of them have not yet made a release, a year or more later.
Because of this, I think that just because someone opts in to following a standard does not imply that they will follow through, so I am not sure what this proposal buys us.
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
Amended that part now
I agree with you there Jennifer and have changed it to a somewhat more negative one now.
But please also see the risk section in the proposal where I say that it should be possible to demote projects that fail to follow through on this scheme.
I also believe this idea will help to better promote all those project maintainers and developers that already does a great job. Some almost applying the core guides even. This would make them stand out from the crowd in the way they really deserve to stand out.
Also, I think we should not underestimate the educational opportunity with a scheme like this. It would draw on the experience gathered over 10+ years into a single document about the best practices of maintaining Drupal contrib projects. Something that most developer have to figure out on their own today.
--
/thomas
T: @tsvenson | S: tsvenson.com
This is a proposal to make a
This is a proposal to make a guide a standard but it doesn't include the guide.
I don't think this proposal can be considered until the guide is written.
I think there are handbook pages where some of this is written already like https://drupal.org/node/467020 and https://drupal.org/core/release-cycle
knaddison blog | Morris Animal Foundation
Thanks for the input
Thanks for the input @greggles. However, those links are about Drupal Core. This proposal is about creating a simplified version of that for contrib maintainers.
--
/thomas
T: @tsvenson | S: tsvenson.com
The core release cycle is
The core release cycle is definitely about core, but could be used to help inform a guideline for contribs.
The other page says:
So, are you basically asking for a way for people to say "I follow that set of guidelines" ? Pinning down at least the basics of the guidelines will make it a lot easier to focus on the proposal (how does someone opt in? does search filter projects based on this facet? etc.) rather than an unknown standard.
knaddison blog | Morris Animal Foundation
The core release cycle is
The thing is that I have today no idea which developers does use those guidelines for what projects. Over time I have been able to learn which developers/project I know I can trust more than others, but that is not an easy task for everyone. Especially not for new ones.
No, but this group was created for brainstorming ideas for d.o and this is an idea I wanted to get some feedback on.
I am fully aware that to be able to implement it a complete proposal draft is need to be made, as well as changes to d.o and relevant modules to be able to both display the badge as well as be able to take it away for projects that doesn't follow through.
Maybe there even need to be a review process or crowd generated process to earn the badge?!
There might even be valuable to explore if there should be more than one badge level and maybe even badges for other things. For example a badge for following the Drupal user interface standards https://drupal.org/ui-standards.
As I mention in my idea post I believe there are many benefits with this, including but not limited to:
I also believe that if this is done right, then it will be motivating project maintainers to aspire to get these badges.
Or how about having badges to show that a module provides an API, uses a third part library and so on.
For me visual guides such as badges helps to get a quick check on what something provides and with 20k+ contrib projects I believe that a carefully selected number of badges can be a valuable addition on d.o.
--
/thomas
T: @tsvenson | S: tsvenson.com