[development] should tinymce get a new maintainer tinymce

Allie Micka allie at pajunas.com
Tue Feb 6 21:23:54 UTC 2007


On Feb 6, 2007, at 2:31 PM, Kevin Reynen wrote:

> HerI see few potential outcomes from this course of action...
>
> 1) drupal-id.com gets pissed and removes me from the project, but
> doesn't address any of the other issues leaving things where they were
> yesterday
> 2) drupal-id.com finally realizes there is a problem with their email
> system, starts to respond and address user issues/concerns
> 3) drupal-id.com continues to do nothing, is removed as the
> maintainer, and everyone interested has a rational discussion about
> how best to move forward

These three options are a no-win.  This is not some power struggle  
and nobody is going to walk away with a prize.  While it's somewhat  
of a privilege to be the maintainer of a highly-used module, it's  
also a huge pain and a thankless job.

The main issue here is that the cost/benefit for maintainership was  
too much for the original maintainer.  Upon stepping down, nobody but  
Drupal-Id picked up the work effort.  The good news is that he/she/ 
they put forth some development effort, the bad news is that this  
came without community involvement, and therefore, the community  
needs where not adequately addressed.

The TinyMCE module is important to our business and our clients.   
Despite this, I'm embarrassed to say that I haven't taken any part in  
working the issue queue or otherwise participating in the care and  
feeding of this module.  Now it has reached a critical situation, and  
many of us have been forced to act reactively rather than proactively.

I don't have the time and necessity to spend on theoretical changes  
(apparently, few do), but the lack of an upgrade path is the key  
matter of importance.  Now, it's useful to fewer people, and making  
this seem like a contentious or competitive situation makes people  
feel even more disinclined to get involved.      It's like "opposite  
day" in open source land.

So now, I have enough motivation to make the time to maintain a 4.7- 
compatible "unfork" at http://drupal.org/project/moxie .  Boris and  
Steve McKenzie have agreed to help address some TinyMCE issues there,  
and we will work on it there for as long as is necessary.

If, on top of clearing issues and meeting the community's short-term  
needs, someone *still* has time to expend on these feature changes,  
then great!   We may have found a "real" maintainer this time around :P


> Meanwhile, I am trying to clear as many issues from the TinyMCE queue
> as possible.  Suggestions about leaving the 4.7 feature requests open
> or pointing those users to the Moxie "unfork" and closing the issue?

As long as Drupal-Id is continues committing to the tinymce project,  
we have no right to remove maintainership, even if we disagree with  
his/her/their decisions.

I really appreciate that you want to help clearing out the issue  
queue - that's the most important thing we can be doing now.  We're  
creating a clean-up rallying point around moxie, and it would be  
great if you could direct issues there.  For everyone else who feels  
like they need a little give/take karma on TinyMCE, please lend a  
hand in this!

Doing it this way lets us dispense with this frustrating discussion.   
Everybody gets what they need in the short-term, bugs get fixed in a  
maintained branch, nobody's getting publicly flogged for their  
development choices, and we can all get back to work.  Later, we can  
revisit a merge when/if one module is bug-free and can address the  
needs of both user sets.


Allie Micka
pajunas interactive, inc.
http://www.pajunas.com

scalable web hosting and open source strategies



P.S.  I don't disagree with the motivations for some of these  
changes, From here, it seems that it would be easier to add the js- 
files-as-editable from the 4.7 interface rather than starting from  
scratch. (by writing them to the files directory rather than putting  
them in a db table).  Keeping what's useful and blending in your  
requirements.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070206/0c5fd7ac/attachment-0001.htm 


More information about the development mailing list