Problem

  • Too little progress, especially on larger changes.
  • Close to zero testing of patches, if there are any.
  • Missing focus, developers working on too many fronts, efforts galvanize, demotivation.

Goal

  • Improve Wysiwyg more quickly.
  • Force users to test.
  • Use developer resources more effectively.

Details

  • There are several larger patches in the queue, which did not see the level of attention they deserve.
  • Since the d.o migration to git, we additionally have entire feature branches, which equally don't get the attention they deserve.
  • In general, most patches for Wysiwyg are written, reviewed, and tested by project maintainers only. Most users of Wysiwyg module are either end-users, or if they are developers, then they may not have the required JS skills/experience to contribute.
  • Many patches are written for particular editors only. We expect most patches to change all editor implementations. Perhaps we're asking too much from contributors. Perhaps it's our job to complete contributed patches.
  • In order to make progress, we need to focus.
  • Release early, release often.

Proposed Procedure

  • A new stable release of Wysiwyg is scheduled for the last Wednesday of each month. A new release will only come out on this date if it's deemed by the maintainers to contain enough important changes to warrant a release.
    • This is also the new point release schedule for Drupal core, as proposed here and formalized here.
    • Users may update Drupal core and Wysiwyg in one fell swoop.
  • Every month, developers will focus on a few improvements. Let's call that a sprint. Comparable to agile development (e.g., Scrum).
    • Other possible improvements are mostly ignored, with the goal of getting the focused-on issues done (i.e., "done" = documented, tested, committed).
    • Wysiwyg is FOSS. There's no guarantee for developers being available or motivation to exist for the current sprint targets. Because of that, incomplete work may be accepted (committed), in order to get an issue off the table and shift focus to other issues.
    • No more than 3 sprint tasks per sprint. (This number may be adjusted along the way.)
    • Sprint tasks are tagged with sprint by project maintainers. (Responsibility may change along the way.)
    • Done issues will disappear automatically, new issues are tagged ("added") for the next sprint.
    • Hence, focus on this view.

Note the purposively generic issue tag "sprint" -- it allows everyone to build a sprint queue for your custom/favorite list of projects:
http://drupal.org/project/issues/search?projects=&status[]=Open&issue_tags=sprint

---------- OP ------------

First, I would like to thank all the people who have been involved in this module so far. With your help Wysiwyg has come far but we intend to take it even further!

Everyone can support this project's motion forward by Chipping In for Wysiwyg 3.x.
Donating is a great and much appreciated way of contributing without having to get deeply involved in the development process or if you don't know any coding at all. Especially if you work with Wysiwyg on a daily basis and using it saves you a lot of time.

We have earlier put together a list of things we'd like to see in the next major version of this module: Wysiwyg 3.x - Wrapping it all up but the response was very low so we're hoping for a better one here.
We are still in the early stages of getting to 3.x, this is the time to post your own ideas and suggestions to add to the above list.
Maybe someone you know has a few ideas too? Bring them and as many others as possible in here. They don't need to be developers, anyone using [or wanting to use] the module is welcome!

If you're the maintainer of another module which you would like to see working with Wysiwyg but something is currently hindering you, please let us know what's missing. (Note: regular support questions go in their own issue, this is for completely new features which are currently not in Wysiwyg 2.x.)

So, spread the word, brainstorm and please chipIn! =)

Comments

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Anyone who has ideas on what they would like to see in the next major version of Wysiwyg?

NiklasBr’s picture

NiklasBr CreditAttribution: NiklasBr commented

I have two ideas: Some editors allow a more advanced/fine-grained control over button order. Some support for that would be a nice addition. Also, something that is perhaps a bit TinyMCE-centric but I would like anyway is the option to toggle windowed/modal dialogues.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Thanks for your input. We're currently working on button ordering (for all editor that support it) in #277954: Allow to sort editor buttons and the settings you mention should have a GUI widget once we get #313497: Allow configuration of advanced editor settings in. Both issues are blockers for Wysiwyg 3.x.
You can already change that setting via code by implementing hook_wysiwyg_editor_settings_alter(), more details on that in the previous issue. Not ideal for something so simple, but it works and there's no need to hack the module.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Anyone else?

NiklasBr’s picture

NiklasBr CreditAttribution: NiklasBr commented

Another idea (though low priority) that would be nice to have is a solution to the flash of unformatted content that appears when WYSIWYG forms are submitted. It is a bit on the ugly side letting users look at html markup for a second while the browser is working out stuff with the server.

I suppose this is because the module needs to transfer content from the editor to the standard provided bu core, but there could perhaps be some way to hide this?

wingflap’s picture

wingflap CreditAttribution: wingflap commented

With regard to button re-ordering, it would be nice to be able to insert blank placeholders to be able to separate groups of buttons. It would also be nice to be able to have distinct rows into which buttons can be placed. That way you can have, for example, the 1st row be the basic formatting (bold, italic, justify, etc) and the second row be styling, third row of table stuff, etc...

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Component: Miscellaneous » Code
Category: task » feature
Priority: Normal » Major
sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Title: Wysiwyg 3.x brainstorming » Wysiwyg battle plan

We need to make faster progress on various larger issues.

I've updated the issue summary with a battle plan.

Any kind of feedback extremely very well pretty much welcome :)

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Issue summary: View changes

Updated issue summary.

thedavidmeister’s picture

thedavidmeister CreditAttribution: thedavidmeister commented

maybe i'm the only one who feels this way, so feel free to take the following with a large grain of salt:

IMO this #1060846: Exportables and Features support for 6.x and #624018: Exportables and Features support for WYSIWYG 7.x are actually quite important to resolve if you want more "developers" and less "end users" lending their time to the forward momentum of this project. the issue has been open for 2 years and if we could push to get these patches RTBC and committed, it would be amazing.

TBH, i spend very little time testing or debugging WYSIWYG mainly because it takes so darn long to set up on a fresh install for baseline functionality. By the time i've finished ticking all the same boxes, and cross referencing all my input formats within my current project and against older projects (thank god i can use drush make to download the js libraries, i know many people wouldn't be aware of drush and would be manually downloading those libraries every time), i've temporarily exhausted all my developer-y goodwill, wasted a bit of my client's money, and i don't really want to spend any more time exploring new functionality or testing patches.

all i want is to be able to export WYSIWYG presets in my Features that i use during development, so i can review new settings/patches/features periodically, in line with my personal workflow and development cycles.

put it this way.. if you'd freed up half an hour of configuration per site on average, and there are 125397 sites reportedly running this module, you'd have over 60,000 more potential hours from the community by now and possibly wouldn't need to be "sprinting" code just to get patches tested.

incidently, lullabot put together a little writeup on the fiddly-ness of WYSIWYG here: http://www.lullabot.com/articles/wysiwyg-feature (WARNING: the patch they suggest fails against WYSIWYG 2.4)

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Thanks, @thedavidmeister, for your honest feedback; that's exactly the kind of input I wanted to hear about.

Your proposal and arguments for that particular issue are sound, too. However, from a maintainer's perspective, there are currently around 50 other bugs and tasks in the queue that are equally annoying. While that issue is important for you and others, some other issue is important for others. But each one of them requires solid code reviews, testing, and possibly further work to finally get them done. What I'm trying to resolve is the problem space and fact that we have a full range of issues that would have a great impact on further development, but we cannot work on all of them in parallel.

thedavidmeister’s picture

thedavidmeister CreditAttribution: thedavidmeister commented

i do understand that. i'm not really intending to complain about the "annoyingness" of those issues i specifically mentioned. Although i have personally spent nearly 5 hours chasing down how to get Features working with my Aegir setup in D6, and still haven't quite cracked it, that hardly concerns anyone else. That's simply the nature of the open source beast.

honestly, if we're going for "most annoying", i have some un-resolved issues getting Microsoft Word to play nice with my WYSIWYG profiles that are truly infuriating :P

what i was trying to say is that it was specifically mentioned that the maintainers are frustrated by the high ratio of "end-users" to "developers".

if that's the case, you may want to try to identify and prioritize bugs/features that, if unresolved, will continue to consume the most of the community's *combined* time and attention on a day to day basis, as we're all humans subject to fatigue and distractions :(

using this logic, something that churns through half an hour of a user's time (whether "developer" or "end-user") on every project, would become more important than a bug that totally breaks WYSIWYG in 0.1% of use cases, or wastes 10 hours of 1% of project's dev time.

all that being said, i'm obviously not that familiar with the maintainer's preferred workflow, so feel free to ignore me :P

j0rd’s picture

j0rd CreditAttribution: j0rd commented

+1

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Sun asked me to provide some feedback on this and while I'm normally able to come up with a wall of text for just any occasion, this had me a bit stumped... Not in a negative way tho, the battle plan and the following discussion has so far summarized the concerns I've been having about this project really well, so I don't have much to add.

@thedavidmaister, I think we have already identified some of those items based on the questions we most often see in the queue. Much of it is already on Wysiwyg 3.x - Wrapping it all up. That list does however not add any priorities to tasks, which I think is a good thing over there since a discussion about the priority of certain points would most likely take attention away from the whole picture and ultimate goal. What's maybe not so good is that the main reason for, or impact of, several of the changes aren't obvious to those not familiar with the actual code.

thedavidmeister’s picture

thedavidmeister CreditAttribution: thedavidmeister commented

@ TwoD

the main reason for, or impact of, several of the changes aren't obvious to those not familiar with the actual code.

fair point.. i would say that that is often the case for anything based on code. Don't think you can do much about that :P

incidently, i just discovered your hook for altering settings in a profile programatically - which lets me do a lot more in terms of importing/exporting configurations, even if it is a bit of a hack/workaround. I would still love to see a features integration - cTools is mentioned in that link you posted, that sounds like a great idea and something that could maybe, possibly, potentially be backported to D6 once done???

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Yes, it could maybe, possibly, potentially be backported to D6 once done, perhaps with the help of other modules. Can't give a more precise answer than that yet, I'm not that involved in the whole Features/Exportables situation. ;)

Bernsch’s picture

Bernsch CreditAttribution: Bernsch commented

When is the next release from the 7.x-2.x-dev branch? --> recommended release 7.x-2.2 ?

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

@Bernsch: See #1340052: New Wysiwyg 7.x-2.2 Release?, thanks.

Artis Krumins’s picture

Artis Krumins CreditAttribution: Artis Krumins commented

FYI: ChipIn on February 4 announced the discontinuation of their service and on March 7 they shut down completely.

Artis Krumins’s picture

Artis Krumins CreditAttribution: Artis Krumins commented
Issue summary: View changes

Updated issue summary.