>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2186377. --> Reported by: [mgifford](https://www.drupal.org/user/27930) >>> <p>I think we all have our own way of evaluating how stable a module is. Sometimes we just know/trust the developer and have had good experiences with other code that they work on. Sometimes it's critical mass (if 100k sites are using it, it's got to be stable, right).</p> <p>Following from <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupalorg/-/work_items/2185511" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupalorg/-/work_items/2185511</a></span> I think we should to start exploring ways of defining what that means and ensuring that we have an automated means of evaluating it. With that we can start rewarding modules that are following that best practice.</p> <p>Modules that are well maintained should be featured on the d.o site (possibly on the home page, but there's an option to do this in lots of other places too. The DA knows what the high profile pages are and having your module featured in this list should be a big deal. It should drive users, but also clients &amp; contributors. </p> <p>I do think it would also be nice to have some sort of visual acknowledgement on the project page that this module meets a set of agreed upon rules about what it means to be a well supported module. </p> <p>Partly this is a matter of determining if the project has critical mass. </p> <p>So I'm going to throw out a few ideas. I hope some of these will be shot down and that folks will come up with others.</p> <ol> <li>No bugs in the issue queue open &amp; active for more than a year. Bonus points may be given if feature requests are submitted &amp; fixed. </li> <li>RTBC'd items wait no longer than 1 month before getting into the git repository.</li> <li>If there is activity on dev, see that a stable release is made every year. (possibly a commits in git / issues fixed since the last stable release)</li> <li>If there are open bugs, see that there is activity in git every 6 months</li> <li><del>Clean response from a Coder Review</del></li> <li><del>Only rank modules with over 500 sites using it.</del></li> <li>A solid documentation page (or more)</li> <li>Not having a alpha or beta release sit in the recommended release for more than 2 months</li> <li>Making sure that there is a proper recommended release</li> <li><del>Not having a security update (although perhaps this would pose a security concern with people hiding security issues so that they don't loose status)</del></li> <li>Bonus points for supporting both official Core releases</li> <li>Providing a dev version of the D8 release (when in alpha).</li> <li>Number &amp; activity of maintainers - let's not forget about the <a href="http://en.wikipedia.org/wiki/Bus_factor">bus factor</a></li> <li>Bonus points for Under active development. Negative points for Seeking new maintainer or No further development. Loose all points if Abandoned or Obsolete. </li> <li>Bonus points for having an image on the project page</li> <li>Including SimpleTests or Unit Tests in the code where applicable</li> <li>Provide appropriately long and meaningful release notes with each new stable release identifying what changes have occurred. Issue queues should be referenced and there should be at least 1 line of description for 100 lines of code. </li> <li>Enable automated testing in the Project.</li> <li>Is there a README.txt &amp; INSTALL.txt file? No other alternates will be credited, consistency matters.</li> <li>Is there a CHANGELOG.txt and does it change with ever stable release?</li> <li><del>Is there some evidence of use of translation? Any t() strings?</del></li> <li><del>Modules should get points for being around for a while. Seniority matters too.</del></li> <li>Is there a teaser in the project description so that it is easier to understand the project's purpose?</li> <li>Is the project description at least 500 characters?</li> <li>Are there headings for: Overview, Features, Requirements, Screenshots, Known problems, Links to Documentation, Pledges, Credits, Recommended modules &amp; Similar projects</li> <li>Is the ratio of downloads to installed sites more than 5:1?</li> <li>Are there translations available?</li> <li>Are users who contribute patches recognized in the git commits?</li> </ol> <p>I don't know how many of these are actually testable.</p> <p>If we could test all of these things, we'd probably have a pretty small list of modules included. </p> <p>But if the bar was set right and was transparent it could be a great motivator. Drupal shops might be willing to put in the extra effort to see that their logos were prominently displayed on the project page &amp; ensure that they give their staff extra time to ensure that the module that they maintain is properly maintained. </p> <p>Thanks @tim.plunkett for these links to existing best practice documents:</p> <ul> <li><a href="https://drupal.org/node/7765">Best practices for creating and maintaining projects</a></li> <li><a href="https://drupal.org/node/363367">Best practices for co-maintaining projects</a></li> </ul> <p>The ultimate indication of mastery is what we do. Our modules/themes need to highlight that, but there should be enough incentives so that people and organizations have the resources to do it well <a href="https://groups.drupal.org/node/410503">https://groups.drupal.org/node/410503</a></p> > Related issue: [Issue #2172251](https://www.drupal.org/node/2172251)