It's really great to see the work done with this module. As you know there are over 188k sites using this module. With CKEditor used in D8 Core, this is the wysiwyg module many are choosing to use. The documentation looks good. It's great that you've just put out a new dev release. I'm assuming that this will lead to a 7.x-1.14 release sometime in the next month or two if all goes as planned.

I do like that you are requesting that users can add this as a favorite on drupalmodules.com, but I am looking to see if there are other ways that we can shape d.o so that user participation is shaped so that there is more participation in making this module better. Increasing popularity is always good, but there should be a way to leverage this module that so many people use to make it better for everyone.

There are also 4 pages of open D7 bugs for this module. This isn't particularly high or low for Drupal contributed modules, but it's more than I think it should be. Not that the maintainers aren't doing a heck of a job trying to keep up, but I do think that the structure of d.o's issue queues really does nothing to put clean up the issue queues, but out regular maintenance releases and ensure that questions from the forums & issue queues get put into the formal documentation.

I do think that there should be incentives to ensure that people who are contributing to it are recognized. There should be some motivation to go through the issue queue and see that reports that people have made are acknowledged, repeatable, fixable and eventually closed. This is a lot of work, but there should be some acknowledgement done for those who are tending the issue queue, but I don't think that's enough.

I've blogged about the use of Flattr & Gittip. The latter brought up some great discussions about initiatives like Top Shelf Modules and DrupalFund.us.

Adoption of any of those platforms seems to be pretty slow though. Gittip has the greatest acceptance on d.o because there is at least a form on each users Profile page to add it in, and yet, there has been marginal increase in the adoption or donation rates https://www.gittip.com/for/drupal/

I tried to highlight how Gittip could be incorporated into d.o's issue queue in order to provide incentives to individual contributors. From feedback there, I decided to look at how Corporate logos could be incorporated into the issue queues (even for anonymous users).

None of these solutions is without it's problems. Some of these solutions will work better to support some projects than others. I think there are probably hundreds of other ways to help shape participation in the Drupal community such that end users, developers, designers and Drupal shops are able to find easier ways to contribute back. But I think we need to get the conversation moving about how to see that important projects like this get the support that they need to see that they are properly resourced.

There's a place to discuss Drupal.org improvements in GDO but there isn't a lot of active participation there.

Ultimately, what kinds of UI changes would help make this module better maintained? For folks who are active contributors, what would help you? Each project may have it's own ideas about how to best motivate the community that uses it's code. It might be that folks are confident that there's no need to change anything, and perhaps they are right.

I would like to know when we can expect to see the next stable release of this module and think it is great when there is a meta issue queue to gather the issues that should go into that next release. I couldn't find this, but if it doesn't already exist it can be started here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jcisio’s picture

Generally I'm in favor of periodical release but without any kind of roadmap (except for big feature requests). With changes, mostly bug fixes, since the last 1.3, it would be indeed great to have the next stable release.

I don't have permission to publish new releases. I'll contact other maintainers.

mgifford’s picture

Thanks @jcisio - I think as a community we need to figure out what is a well maintained module and how to set up systems to make that easier #2186377: Highlight projects that follow Best Practices

Lots of us really appreciate the time that goes into maintaining this code base!

wwalc’s picture

Thanks Mike for your kind words!

Let me explain the status of the CKEditor module: we spent quite a lot of time on developing versions for Drupal 5/6/7 and from some point, things got quite stable and reached the status where basically two things can be done:
a) work 24/7 on further improvements (there are lots of things I would love to fix&change) or
b) simply keep it at usable: ensuring that nothing new will break, till Drupal 8 is out and D7 is widely used.

The sad fact is that I (personally) have very little time and CKEditor team is already doing quite a lot together with Wim to provide an amazing feature for Drupal 8. So when having a choice to invest time into something that will “soon” be gone OR work on something that will be really really cool, we went with the second option. To keep the D7 module development going, we'd simply have to hire a dedicated developer. Our team is constantly growing, but still it's relatively small to do this kind of investment.

There is one more reason why option "b" seems to be more tempting (apart from the lack of resources): the WYSIWYG module which is an interesting alternative if one finds some limitations in the CKEditor module. I really admire the work that sun&TwoD did. In Drupal 7 people have two options on enable CKEditor, each one have some good and bad sides.

Option "b" does not exclude enhancements, though they are somewhat limited to:
- adding patches posted by other users (I would love to be able to use simply pull requests @ github...)
- adding enhancements to keep the module compatible with new versions of CKEditor (e.g. the possibility to disable ACF was a good example)

I do think that there should be incentives to ensure that people who are contributing to it are recognized. There should be some motivation to go through the issue queue and see that reports that people have made are acknowledged, repeatable, fixable and eventually closed. This is a lot of work, but there should be some acknowledgement done for those who are tending the issue queue, but I don't think that's enough.

Well.. I think you identified quite well the problem. Take for example Stack Overflow. People are active there (also) because they can get points & badges for every single answer they provide. It really encourages you to be more active, even if everything is quite virtual. If you are rewarded in any way, you tend to like such thing more.

BTW.

#2138397: Highlight Flattr, Paypal or Whatever Opportunities on Issue Pages
#2186377: Highlight projects that follow Best Practices

Both ideas are really great imho.

None of these solutions is without it's problems. Some of these solutions will work better to support some projects than others. I think there are probably hundreds of other ways to help shape participation in the Drupal community such that end users, developers, designers and Drupal shops are able to find easier ways to contribute back. But I think we need to get the conversation moving about how to see that important projects like this get the support that they need to see that they are properly resourced.

That’s a good question for which i don’t know the right answer… I only know that once your module gets really popular, maintaining it becomes a quite demanding part-time job. If you want to give feedback in each issue, investigate issues locally, work on fixes, enhancements and so on. At some point it becomes impossible to do this right.

Ultimately, what kinds of UI changes would help make this module better maintained? For folks who are active contributors, what would help you? Each project may have it's own ideas about how to best motivate the community that uses it's code. It might be that folks are confident that there's no need to change anything, and perhaps they are right.

Instead of suggestions, let me just list a few things that I saw that really work:

Voting for issues - I like the Rackspace approach where iirc you have certain numbers of votes that you can use and you can add +3 for example to some issue. Together with sorting issues by the number of votes it could help in dealing with a huge backlog.
#42232: Help Maintainers Manage Issue Priority by Encouraging Voting - 9 years, waiting :-)

Github + pull requests ;-) I love the situation when I simply get an email when there is a pull request and it takes me seconds to approve it if the change makes sense. The less time some operation takes, the more things you will do in the same amount of time.

Better scoring/reputation system for users. People that will gain some reputation just for being active on forums, issue trackers etc. will feel more appreciated. After all not only “coders” who get credits in changelogs keep Open Source projects alive.

I would like to know when we can expect to see the next stable release of this module and think it is great when there is a meta issue queue to gather the issues that should go into that next release. I couldn't find this, but if it doesn't already exist it can be started here.

Within a month I believe / hope. There is one feature that I plan to introduce to have a new release: support for CDN.
This way there would be no requirement to upload the CKEditor library when installing this module. This was my dream since the beginning in fact. I really hate this complex installation procedure. First you get a CMS with a plain textarea, which is an interesting surprise, then after some googling you find that there is a module called CKEditor which enables WYSIWYG editing but guess what, it comes without the editor!! Wooot :D
The official CDN should help in solving it. Basically the module out of the box will load the “CDN” version of CKEditor, until someone decides to upload the editor locally to the libriaries folder (e.g. a custom build or something).
The CDN is “under construction” let’s say, we have one last technical issue to be fixed first.

Thanks a lot for your feedback!

wwalc’s picture

Last thing - regarding release planning, jcisio explained how the situation looks like at this moment.

@jcisio - About permissions: I already pinged you @ Tweeter about this. I have no idea why you did not have the "Administer releases" permissions (I mean I know, just it's hard to admin that I forgot to set it). I fixed it soon after I saw your comment. Thank you for co-maintaining this module!

mgifford’s picture

I appreciate your feedback @wwalc

Although I like the idea of a) it doesn't take too long before that just doesn't work for maintaining anything :)

5X more folks use the D7 version of your module than the D6 version, so think that you've gotten the widely used now that there are 203,315 sites claiming to use a D7 version. That's amazing!

It's pretty common for maintainers to complain about having very little time. That is a reality. Even if at one point you could put 100% into this module, it's impossible for anyone to sustain that. At some point life gets in the way of one's best intentions and you have to make compromises. If there are no incentives professionally to maintain it and all there is is a sense of guilt or someone nagging you to do something on Twitter. It's just not enough to do what needs to be done.

This is a much bigger systematic issue that is affecting many popular modules.

It's definitely an interesting thing when a Contrib module gets pulled into Core. I've been involved a bit in that side of things too and it has been interesting to watch. Generally the bright minds go to work on the D8 version and the D7 version goes a bit stale. This is understandable, but really the community could be doing more to encourage others to step up to the plate and take on roles in modules like CKEditor & Migrate when they are popular enough to become part of the next release of Core.

We do totally want to have a kick ass release of D8 including a great, accessible WYSIWYG editor. We also want to see that for sites we are building & maintaining over the next 4-5 years have code that is being at least minimally maintained.

I do totally understand the pressures of balancing community contributions in a small business.

I definitely liked the abstraction idea with the WYSIWYG module. As you know better than most, there are some disadvantages with this approach.

I think that the Github style pull requests would need to be dealt with here https://drupal.org/project/issues/infrastructure?categories=All

It's come up before though for sure and Github provides an interesting model for all kinds of things (like project descriptions). Because I couldn't find it I added #2205815: Merge requests in Drupal.org issue queues?

There are risks with Gamification (or whatever it is you want to call what StackOverflow is doing) #2203401-4: Add Open Badge Infrastructure

Certainly it is a term that I've recently learned people have rather extreme views around.

The community needs to think about the risk of adding a dopamine hit to the value of and type of responses we get in this community. It certainly needs to be done carefully.

Glad you like some of the issues I've posted as Drupal.org Customizations issues. It would really help to have a few folks chiming in to say what they like or don't like about them. Ultimately, it's when there's a critical mass of interest in an issue that there will be the political will to implement & evaluate it.

This is a good nugget of wisdom:

I only know that once your module gets really popular, maintaining it becomes a quite demanding part-time job. If you want to give feedback in each issue, investigate issues locally, work on fixes, enhancements and so on. At some point it becomes impossible to do this right.

I do think we can do a better job of supporting module maintainers when their module starts to gain popularity.

In terms of the ideas you think can work:

A CKEditor CDN would be great. I'm looking forward to seeing that!

rootwork’s picture

There now hasn't been a stable release in 1 year 6 months, and the last commit to dev was almost exactly 1 year ago. Nonetheless, there are numerous fixes on the dev branch.

Would it be worth coming up with a plan for a release with dev's fixes, even if a bigger release is planned for some time in the future? This issue seems to have been dormant for 3 years, so I'm not sure what the status of the plan even is. At this point I'm using dev in production because I have no choice, and I suspect others are too.

jcisio’s picture

Status: Active » Fixed

Several stable releases have been out since there, so I'm closing this issue.

rootwork’s picture

Status: Fixed » Active
FileSize
46.09 KB

@jcisio Are they posted somewhere else? Because this is what I see on the project page:

releases

Where are the "several stable releases"? I would love to install them!

jcisio’s picture

Status: Active » Fixed

This issue was created in Jan 2014 (!) and most of the discussion happened at that time to prepare for a stable release. The last stable is in Dec 2015. So I don't think it still has anything to do with that.

I've btw committed some patches. Hopefully we can have a new release soon.

rootwork’s picture

@jcisio If you think this issue is insufficient for the purpose, can you create a new "roadmap for a new stable release" ticket? I'm glad you want to have new release soon, but I think it would be good to have an open ticket tracking that progress, and how people can help.

jcisio’s picture

Personally I don't have any "roadmap" for any module that I maintain. When I have some time I'll check the issue queue for RTBC, commit them and decide if a stable release is needed (if those recent commits are safe etc.). Of course I subscribe to all issues so that I can see quickly any important ones.

So if you want to help, please post patches and review. The last time I checked, for a long time, there were only 6 RTBC issues, and 4 were committable. That said, since the last stable release was 18 months ago, I went ahead and have just created a new one.

rootwork’s picture

Great, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.