Clearing out the CCK issue queue

Posted by karens on September 30, 2006 at 12:05pm

Update: Things are much improved now with several new committers and lots of people providing patches and reviews and other support. Thanks to all of you!!

The CCK issue queue is almost becoming unusable because it's so large. The same problems keep getting reported over and over again because it's getting so hard to tell if the problem has already been reported. Plus there's a long list of feature requests that bulk up the list. I know that JonBob is probably overwhelmed by the work that needs to be done (I'm not criticising him, he's done an incredible amount of work getting CCK this far), but CCK is critically important to me and I do want to try to help move things forward. I don't want to get into a discussion of what JonBob ought to do. Instead, I wanted to get some discussion about what the rest of us can do.

One thought I had that would at least make things feel more manageable is to break that issue queue up into several issue queues. Move all the issues related to nodereference into their own issue queue. Ditto for text, number, etc. Then the remaining issues will all be cck core (content module) issues. Those core issues are the ones only JonBob can deal with, or at least are ones he'll need to provide input for, so that might make it easier for him to focus. Issues related to individual field modules could be hashed over by the community, or perhaps someone will step up to take the lead for some of them.

You currently can identify issues by field module, but there doesn't seem to be any way to filter your view to see only those issues, so that doesn't help much. Even if there was, many users wouldn't know how to do it and would still see that huge list of issues. It's the newbie users in particular who keep reporting the same things over and over, so it would help to make it easy for them to see what is already reported by getting the list down to a manageble size.

I know we still have lots of duplicates in the issue queue, and there are also probably a number of issues that are no longer relevant, but it is for all practical purposes impossible to figure that out now. As we move issues to their own queues I think we'll be able to more easily find and close those, leaving only ones that are unique and relevant.

This could be done by setting up a project site for each field module and pointing people to those sites on the main cck page. People will still report things in the main cck issue queue, but those of us helping out can easily move them to the right queue to keep things cleaned up. This would help people focus on issues about a specific field module, and perhaps make it possible for someone other than JonBob to do the commits for field modules.

Separate projects could be created in one of two ways:

Creating projects as subfolder under cck:
* They can have their own project page and issue queue
* They still get packaged with the cck download
* The field project page will not have a download link, which confuses people
* The field project page will not show up on the download page at http://drupal.org/project, so people have a hard time finding it
* They can only be created by JonBob, who then would have to grant commit access to whoever is the project maintainer

Creating projects in their own folders
* They can have their own project page and issue queue
* They will have their own downloads and will not be included in the cck download
* The field project page will have a download link
* The field project page will show up on the download page at http://drupal.org/project
* They can be created by anyone with cvs access
* They need to be removed from the cck cvs repository so people are not confused by seeing multiple versions of the module, and so you know that reported issues are for the separate field module rather than the one that has been included in the cck download

Comments

+1 for separated issue queues

Posted by sun on September 30, 2006 at 3:54pm

Issue queues indeed should be separated by module. Each module that's not in CCK core should have its own issue queue in its own project. There should be project components for all CCK core modules in CCK project.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

CCK silence...

Posted by yched on September 30, 2006 at 5:29pm

Each module that's not in CCK core should have its own issue queue in its own project. There should be project components for all CCK core modules in CCK project.

That is already the case. You can filter out the issues for, say, nodereference, using the "advanced search" link.

I think Karen asks that all field modules (including "Core CCK" text, number, noderef etc... fields) have their own issue queue, not relying on the "component" thing, which implies using this "advanced search" thing.
No sure if what Karen describes is possible with current project module, though.

Anyway, +1 on the fact that there is currently an issue with CCK.

External contrib fields modules (date, computed field, imagefield, ...) live their very active lifes : bugs get fixed, features get added. Extremely rich things happen there, which is a sign of the high amount of interest and excitement around CCK.

CCK core and core field modules, on the other hand, are more or less frozen. Patches linger waiting for "official" word / review / approval, everyone more or less has its own "custom patched" version of CCK, which in turn makes submitting or reviewing new patches more and more difficult. This situation does not seem in line with the important focus CCK was given and rightly gained.

Just like KarenS, I do not intend this as a rant against JonBob - what he has build here is truly remarkable, and I do not have 10% of the architecturing / coding skills he put in this, plus he most certainly has excellent reasons for not being around.

I'm not even saying that developements on the CCK framework should go faster - I'm aware of the OSS "things get done when they get done" motto. Plus, given the quality of what's already in, "take your time" is more what I'm inclined to say.

I'm just saying that there's a lot of people out here trying to contribute, work on the issue queue and improve parts or fix bugs, and the current silence is somewhat frustrating.

So maybe separate issue queues and additional commiters for core fields are a solution. What I'd really like is JonBob to be more vocal :-)

I have been working on

Posted by karens on September 30, 2006 at 9:55pm

I have been working on Drupal issues for 6 months now and I never figured out how to filter the cck issue queue down by component. I probably should have, but if I didn't, I'm guessing many less experienced users haven't figured it out either :-)

Yes, the scenarios I describe above are possible with the project module. My current projects are divided between the two methods. Event Views and Location Views live as subfolders under Event and Location, and my other projects are stand-alone projects, and things behave as described above. In both cases, the projects get their very own issue queue which is not shared with the 'parent' module, and they all show up in the project list when you edit issues so you you can move issues from and to them.

One step further ?

Posted by yched on October 1, 2006 at 4:06am

If I didn't, I'm guessing many less experienced users haven't figured it out either :-)

Yes, I just wanted to point out it's possible, not meaning it's optimal. If project module allows for what you propose, it might be good idea.

In fact, I've been wondering for a while now if all 'contrib' cck modules (date, imagefield, fieldgroup, etc...) instead of being scattered around the contrib repository could be grouped inside the cck project, using 'contrib' subfolders (just like image and image_attach), with a structure like :

/cck : core "content" functionnalities
content.info
content.install
content.module
content_views.inc
...
/cck/fields : core field modules
text.module
number.module
...
/cck/fields/contrib : contrib field modules
/cck/fields/contrib/date
/cck/fields/contrib/imagefield
/cck/fields/contrib/computed_field
...
/cck/contrib : other non-field contribs :
/cck/contrib/contemplate
/cck/contrib/fieldgroup

With of course contrib subprojects assigned to their current maintainers

I don't want to hijack your thread, though - maybe my idea is a bad one, and yours is still a good one nonetheless :-)

Storing them under cck is

Posted by karens on October 11, 2006 at 12:17pm

Storing them under cck is likely not going to be the best option. It looks like the plan is to move away from that and stick with stand-alone projects (see http://drupal.org/node/86863#comment-159886).

All right, then... :-) Does

Posted by yched on October 11, 2006 at 1:03pm

All right, then... :-)
Does this also impact your initial ideas about core cck modules ?

I believe the only way they

Posted by karens on October 11, 2006 at 1:22pm

I believe the only way they can get their own issue queues is if they are set up as separate projects, so I guess that's what I vote for.

CCK logjam

Posted by RayZ on October 10, 2006 at 7:49pm

At this point anything that would help JonBob with distributing the load of stuff that quickly piles up waiting for him would be a big step forward IMHO. Unfortunately, this proposal also requires JonBob's blessing. So, while I think it's a good idea, we're still stuck in a catch 22.

Tree-like hierarchy of CCK features

Posted by mki on December 12, 2006 at 1:04pm

My concept is that we need describe CCK as tree-like hierarchy of features. I don't know CCK enought to present such tree. But it should be something like this:
-- Core
-- Data storing
---- Fields
------ fieldgroup
------ nodereference
------ number
------ text
---- ...
-- Data processing
---- ...
-- Data displaying
---- Fields weight
---- Views integration
---- ...
-- Data entering
---- Validation
------ Allowed values
------ ...
---- Widgets
------ textfield
------ ...
-- Documentation
---- ...
Not much experienced users usually can describe what is wrong when they look at the screen, but they can't categorize it in strict computer language. So if we present to them this "map" in clear and palatable way (e.g. diagram and simple and intuitive label for all elements), they could be more maturely categorize and describe own issue, and search existing issues. I know that from my own experience :). It will be good if we can display list of issues by every category in this tree structure. Currently we can do it by module names by using "advanced search", but this is insufficient -- users may don't know what module is responsible for errors or features, that why in my demonstration tree I give modules names up. To sum up: not names of code pieces, but intuitive names of features on big tree diagram! Every tiny feature should be noted. As I said, can't provide proper structure of CCK, but I can convert ready text to diagram :) (and provide source file in OpenOffice.org Draw format for alterations). If this is good idea, we need well thought out main categories for categorizing child features.

I can appreciate that it's

Posted by karens on December 12, 2006 at 1:14pm

I can appreciate that it's hard for end users to know for sure which module is causing a problem, but categorizing it by module is the best method of categorization for committers, since we often work on one module at a time or look for related issues for the same module. Don't worry too much if you don't know where your issue belongs. Someone who does know will re-categorize it. Just provide as much info as you can about what you have installed and what is happening.

My counter-arguments

Posted by mki on December 12, 2006 at 1:39pm

My counter-arguments:

This will be good documentation: what CCK can do, how CCK work and what are relationships beetween features, where we can find this features?
We will reduce number of duplicated issue and don't wasting users time on describing existing issues.
We can provide tree-structure support modules and features categorization.
Many features work via many modules: how we can categorize it?
We can utilize users potential, when they will know what they are talking about.

CCK Handbook

Posted by karens on December 12, 2006 at 1:42pm

You'll find the beginnings of documentation in a new CCK Handbook at http://drupal.org/node/101723. It still needs lots of work since it needs to be written by people who know CCK very well, and most of us are really busy with other things right now, but it's at least been started. That would be the place to put things like what you are describing, rather than in the issue queue. You can post ideas about the handbook at http://groups.drupal.org/node/1986.

I can't

Posted by mki on December 12, 2006 at 1:56pm

Thank you KarenS. it needs to be written by people who know CCK very well, and most of us are really busy with other things right now If I can do it myself... there's no way I can do it :(. I will put link to our comments where you showed. If I try I could compromise myself :).

You can still help by

Posted by karens on December 12, 2006 at 2:30pm

You can still help by indicating what is confusing, so someone can get an explanation into the handbook. Or it can still be helpful if you create something that describes what you do understand that we can see how people are interpreting the information that is available. It is very valuable to get input from end users since we really need to know how things look to people who are not experts in using it so we can better explain things.

Thanks for your input!

tips from ecommerce experience

Posted by sime on December 11, 2006 at 10:44pm

Hi KarenS

I've been trying (not succeeding!) on and off to tame the ecommerce queue which is 18 pages. The first thing is to not stress about this. Once you realize that it's impossible to herd all of the lemmings home, you'll feel a lot better. :-)

Best advice - bump quality tickets
When jonbob looks at the queue, he will see a lot of crap. If you find an important ticket on page 3, comment on it (eg. simply state why the issue is important). In this way you increase the quality of tickets at the top of the queue. Then, when jonbob looks, he can get a much better feel for the issue if someone knowledgeable has affirmed it. This reduces the frustrating stop/start that happens to developers trying to work through a messy queue.

Another truth is: once you start it gets easier. Perhaps 80% of issues (eg. support and bug) are already solved, and you can only become familiar with these if you attack the queue and accept the occasional mistake.

Here are some other things that I do.

close old support tickets with "fixed" (assume the user is ok now)
"won't fix" very old feature requests. If they haven't been done yet, chances are they won't be.
I often work from the back of the queue. This tends to be more satisfying because more often the action is clear.
close badly defined bugs with "please reopen if you can provide better information.
postpone good feature requests that are unlikely due to resources. This will give jonbob a useful way to review feature requests that you see merit in.
Try to bump up bug tickets that have patches. These are the most important IMO and are the most constructive types of ticket for the dev to act on quickly.
If in doubt (#1) - add a comment: "please confirm if this is still an issue". This will allow you to close it without guilt after 2 weeks of no confirmation.
If in doubt (#2) - assign to yourself. Sometimes I see bugs or support questions which I don't quite have the immediate answer for. Chances are in 4 weeks I will know it off my head. I self-assign for this type of thing.

And...
Important! Where the action might offend, I always put: Please re-open if you feel there is an error. The ticket creator will see the issue in the "recent posts" page, and they can follow up if necessary. Frankly, I err on the side of brusque (after all, apologies can be made, and tickets can re-opened).

Since you are an experienced drupaller, I'm sure I've told you things you already know. But I hope some of this is useful.

Simon

Thanks Simon for your ideas.

Posted by karens on December 12, 2006 at 1:03pm

Thanks Simon for your ideas. Actually things are much improved now. There are several new committers (I'm one of them) and we've whittled the list down from 13 or 14 pages when I first posted this to 7 or 8 pages, even though lots of new issues have been posted since then.

Anyway, your ideas are good ones for anyone else who has time and interest in getting that issue queue whittled down even more.

Thanks!