Offer to co-maintain WYSIWYG; restructuring project engineering and maintenance

Problem

I feel we need to restructure the code and maintainership of this very important module.

As per TwoD's comments here:

https://www.drupal.org/node/1953106#comment-8732183

He's been working very hard on Wysiwyg, but because of his work schedule, and the increasing complexity of new Wysiwyg editors, we're unable to produce releases in a timely manner - the last release was published almost 4 years ago. TinyMCE 4 was released in 2013 and is still not supported in the latest stable release of Wysiwyg.

Proposal

1. Spread out the workload so that TwoD isn't responsible for everything

   I volunteer myself to help maintain Wysiwyg. I think it would be great if we had at least two other developers to help co-maintain (other than TwoD and sun).

2. Create a release schedule
   For example, publishing a 7.x-2.x release every X months, and a major release every Y months.

   As mgifford mentioned,

   There are "no security advisories for development releases" [ (including (-dev), ALPHAs, BETAs or RCs." ]

   Therefore we can't leverage the security infrastructure in d.o when security problems are established.

   It's not a best practice to update every time there's a new dev release. Formal releases make it way better for site owners to know when, how to upgrade their modules.

3. Clear out old issues in the issue queue

   There are currently 289 open issues, and 72 open bug reports, with the oldest ones being over 7 years old.

4. Consider API breaking code changes for 7.x-3.x

   TwoD mentioned struggling to make changes while keeping backwards compatibility with the many modules that depend on Wysiwyg.

   We should have a hook_wysiwyg_api() similar to hook_views_api() so that modules can explicitly declare their version compatibility. This will also allow us to iterate through major code changes.