Some discussion with webchick in IRC led to the idea of a free-tagging vocabularly on drupal.org to allow for some parallel categorisation of issues alongside feature/bug/review/needs work. i.e. needs benchmark, needs re-roll, needs doxygen etc.

For more see: http://groups.drupal.org/node/6809

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Project: Project issue tracking » Drupal.org infrastructure
Version: 5.x-2.x-dev »
Component: Issues » Drupal.org module
webchick’s picture

Yeah, I thought this might be a better idea than 1,000 more "needs *" issue statuses, because:

a) It's really hard coming up with that many distinct colours. ;)
b) Issue statuses require "top-down" coordination... people need to convince one of the site maintainers to add it, we argue back and forth for 3 years about what precisely it should be called, etc. Tags, conversely, would present the opportunity for ad-hoc, bottom-up coordination. "Hey, let's tag all the issues we want to work on at BADCamp as 'badcamp07' so they're easy to find!"
c) I wanted to start a new contributor initiative to "tag" issues as "good for newbies to patching" ... unfortunately the only way to do this now is to create a new user account ("patchnewbie"), login as them, assign the issue to myself, and then log out and back in as me again. Tedious.
d) You can easily subscribe to RSS feeds like "newbie", "documentation", etc.

But there are lots of cons, too...

a) Most importantly, there'd be no way to say "get me *only* the Drupal 6.x issues that are tagged newbie" but rather, "get me all issues across all projects tagged newbie" which is probably less useful. Not sure if this could be worked around programmatically or not.
b) There really isn't a way to know what all feeds exist. You have to either luck into finding one, or you have to be a site admin on d.o who doesn't mind paging through 50,000 pages of terms. We might be able to generate a page programmatically where, if > 5 issues were tagged a certain way, the term would show up in the list, though.
c) We are likely to get a mish-mash of tags, some (most? :P) of which won't make any sort of sense. Especially from people who mistakenly separate tags with spaces (ugh).

Pasqualle’s picture

How can a bug tracking system be even better?

+1, very clever idea

dww’s picture

Project: Drupal.org infrastructure » Project issue tracking
Version: » 5.x-2.x-dev
Component: Drupal.org module » User interface

- There's nothing inherently drupal.org specific about this request.

- This is an interesting idea, but IMHO a lot lower priority than http://groups.drupal.org/node/6180

In terms of webchick's cons:

a) views might solve that. couldn't we easily export a views filter so people can include these terms in their issue queries?

b) yeah, the "at least 5 issues with this term" stuff should be fairly easy to do. perhaps even via views, but even if not, i'm sure we could get that working fairly easily.

c) this is going to be a huge problem. :( maybe we should add an extra validation step anytime a term contains a space, that forces a user to click through a confirm page. ;)

d) [You forgot one] -- Unfortunately, for this to be useful, there'd have to be a way to modify the tags on issue followups. Sadly, IFAC doesn't make that any easier, so we'd still need some custom code to make this work. :(

(d) would help (c), but we'll still have stale terms in the d.o DB unless site admins can easily clear out bogus ones (or there's a way to automate the task)...

anyway, this is interesting, but needs some more consideration, and definitely someone else to champion the effort and write the code if anyone wants to see this live anytime soon.

cheers,
-derek

catch’s picture

a) Views 2.

b) Tagadelic or similar does this already
c) Yeah that's a problem, although it's a problem with free tagging in general. http://drupal.org/node/142841 this would probably help a lot with it.
d) That's why I originally stuck this against project module, should've left it there but thanks for moving it back.

webchick’s picture

Ah. Originally I was just thinking this was a "create a Tags vocab on d.o, enable it for project issues" thing, but you're right.. there is some code that needs to be done so that people could change the tags with follow-ups. If they could do this, this actually negates the "banana monkey dishwasher" problem, as subsequent follow-ups could correct that same as we do when someone changes the issue title to "Well that didn't work either"

folksonomy_comment module, perhaps? :)

dww’s picture

@webchick: good point. now that we have IFAC, there's no particularly good reason this code has to (or should) live in project_issue. ;) i could imagine other cases where someone wants to enable comments on a node to let commenters alter the taxonomy terms for that node -- witness the existence of http://drupal.org/project/comment_cck for example.

However, that still doesn't solve the "stale terms in the d.o DB" problem I mentioned at the end of #4, since even once a followup changed "banana monkey dishwasher" into "banana, monkey, dishwasher", there'd still be a vocab term in the DB called "banana monkey dishwasher", unless there was some fancy logic in this new "comment_taxonomy" module that when it's updating the terms for a node, if it's removing a term, it queries {term_node} for the given tid, and if there are no records, it removes the term completely. although, that'd only handle the case of pruning dead terms during a comment, not during a direct node edit... oh well, not the end of the world, I guess, and certainly not essential to solve for phase 0...

So, who writes the "comment_taxonomy" module? ;)

yoroy’s picture

Subscribe. And a big +1 from my non-dev wannabe contributor perspective. It would be great to be able to filter issues on things like "user interface", "needs graphics" etc. This would certainly allow more people to easily find a place to contribute.

webchick’s picture

I agree. Assigning to myself. I have a big interest in seeing this done, and it sounds like dww is not too opposed. I'll work up a spec.

Incidentally, the "stale terms in the d.o DB" problem is a problem with core in general, so I don't see a big reason to solve that here.

webchick’s picture

Assigned: Unassigned » webchick

ahem.

agentrickard’s picture

It _might_ be safer to use a fixed taxonomy rather than free tagging. But that means more work for site admins.

beginner’s picture

@webchick: what's your status? You say in #9 you assign this to yourself, but one minute later, you 'ahem'-disassign it...

beginner’s picture

beginner’s picture

webchick’s picture

I just got back from a week doing training and I'm now catching up on stuff. so I probably won't get to it this week or next, but it's on my radar, and high on my non-work priority list, which frees up a lot after the first week of December.

Community tags is kind of clunky. I was hoping for something that fit better with the rest of the project issue stuff, by integrating directly into comments. But maybe it's a patch to community tags so it can be altered from comments, not sure.

webchick’s picture

Btw, if someone else wants to work on it, and has time, please assign it to yourself. Don't wait around for my schedule.

beginner’s picture

I have tested community_tags. It is quite good and goes a long way towards providing what's requested here.
I don't understand the dependence on tagadelic.module.

I think the question now is: what modification should be made to community_tags so that it can be used on d.o.?

beginner’s picture

We cross posted.

community_tag allows the tagging form to be posted in a tab, inline within the node, or within a block. If you want the form as part of a comment, we can add a fourth option to it. But the advantage of the existing choices is that we don't need to post a comment just to add a tag.
We already have a lot of "subscribing" comments for lack of subscriptions.module. Do we want scores of "tagging" comment now? ;)

Or do you mean that we should see each change in tagging within each follow up, the same way we see changes in status, version, etc?

beginner’s picture

community_tag issue:

http://drupal.org/node/191403
integration with project_issues.module

webchick’s picture

I don't even really know if CT is an option:

* It's not currently maintained (see Steven's recent mail to the dev list)
* It's dependent on tagadelic, which doesn't yet have an official 5.x release.
* We want to minimize the number of modules that are installed on Drupal.org, so even if it did have a 5.x release, it would not be the best option.

hunmonk’s picture

i'd prefer to leverage existing code rather than write custom code for the project case -- please look heavily at other modules that can be leveraged before writing any custom code!

and FWIW, i think the "minimize the number of modules that are installed on Drupal.org" is a dying sentiment, and one of the reasons project module became such a mess in the first place. we're trying to head in the other direction now. witness that comment_upload is now running on d.o, views is soon to follow, and subscriptions module will most likely replace project issues' current subscription framework. it's time to let go of that old idea... ;)

webchick’s picture

That still doesn't help with the fact that Tagadelic/Community Tags is still a mess. ;) Not to mention a performance hog, last I checked. But I'll look into it, as I said.

hunmonk’s picture

if the current module is a mess, then in an ideal world i'd like to see:

  1. work w/ maintainer to fix existing problems
  2. integrate it w/ project module using minimal code, if necessary
  3. get a security/code review
  4. deploy on drupal.org

i understand that might be a longer road, but i think it's the right one. minimizing our project* codebase by leveraging other modules is a primary goal, and i don't mind taking the slow route to new features in order to stay on track. ;)

dww’s picture

a) Yes, we want to "outsource" more of project*'s functionality to high quality, well maintained other modules. comment_upload (heine), views (merlinofchaos) and subscriptions (chx) are all maintained by our best and brightest, so that's not a problem. However, we can't just install everything that seems like it might be useful on d.o, because...

b) performance on d.o is a HUGE concern.

c) security on d.o is a HUGE concern. Everything that runs here has to be audited by the security team (preferably by more than 1 member).

Furthermore, I don't think we need anything particularly fancy here. As I mentioned in #7, all we need is something like the http://drupal.org/project/comment_cck module, but "comment_taxonomy". It just form_alter's the comment form to add the taxonomy module's UI elements for the node you're commenting on, and adds its own validation and submit handlers to validate and save the results. Then, for extra credit, if we finally fixed http://drupal.org/node/140473 (which would also solve http://drupal.org/node/190539), this "comment_taxonomy" module could implement the hook that project_issue uses when computing the diff between 2 comments, for use in the d.o UI, in the subscription emails, etc.

dww’s picture

Oh, and to be clear, I think such a "comment_taxonomy" module could be very useful to other sites, not just d.o's project_issue use case. The more *other* sites that use the stuff running on d.o, the better, since there's a wider audience of users and developers who can help test, maintain, port, etc.

I've never used Community Tags/Tagadelic, etc, but it certainly sounds like serious over-kill for our needs. I'd rather keep all the code we have to maintain, audit, and port for d.o as simple as possible for the tasks at hand.

webchick’s picture

@dww: Yes, that's exactly what I was thinking.

People are mentioning Community Tags because it allows users to alter the tags on nodes, by clicking on a "Tags" tab and adding their own. So the functionality is similar, in the broader sense. But it suffers from problems I've described.

catch’s picture

form_altering a new field into the existing comment form sounds great to me, it'd be a shame to have it in a tab.

hunmonk’s picture

yes, i probably wasn't clear enough in my initial posts.

we of course need to watch the quality of modules that we place on d.o -- i've never looked at community tags/tagadelic, so i can't speak directly to their usefullness/quality relating to this particular issue.

i never meant to communicate that we throw up modules on d.o without taking these things into consideration... :) (note the "in an ideal world" prefix to my wishes -- if those modules really are a mess, then we probably won't be able to trust that they'll be properly maintained and fit for d.o)

another new module that does what we need and is well maintained is also a fine idea -- we should just check to make sure that we're not reinventing the wheel before it's written.

dww’s picture

@hunmonk: we should just check to make sure that we're not reinventing the wheel before it's written.

AMEN, brother!!

so, step 1: Make sure something doesn't already exist that's like the "comment_taxonomy" module i describe above. report back findings here.

if (module_exists('comment_taxonomy')) {
* evaluate what stops it from being d.o-worthy
* start posting issues in its queue
* supply patches, etc, etc.
...
}
else {
* write the simple code i outlined above
* commit it to contrib CVS
* make a d.o project node for it
}

* get the security team to audit
* deploy on d.o
* open($beverage_of_choice);

;)

webchick’s picture

Status: Active » Needs work
FileSize
1.89 KB

I grepped pretty extensively through contrib and could not find a module that does this already. comment_cck is the closest, but this seems like a separate use case.

So, enter comment_alter_taxonomy (sorry, I hate those ambiguous object_object module names. bah!).

This is half a module that I whipped up tonight thanks to my good friend, Mr. Insomnia. Still missing the submit handler to actually alter the terms on the node, but otherwise it seems to be working.

* Settings page lets you choose which vocabularies are alterable. So you can make a system-wide decision that "Article Type" is not ever to be monkeyed with by anyone.
* Permissions page gives you an "alter taxonomy on $type content" permission per content type. This allows you to let "authenticated users" alter tags on a node, but not "anonymous users."
* The comment form, assuming the user has access to alter its taxonomy, and that at least one allowed vocabulary is present, gets a form selection for each alterable vocabulary.

This is some serious 4am code here, so it might all suck, but I put it up for comments or whatever. Not sure when I'll get a chance to work on this again. Also not sure where this issue belongs anymore. But it's a start anyway. ;)

dww’s picture

Aww, now that you can attach multiple files to a single followup, you still have to .tar.gz it to make it harder for the rest of us to look at your 4am code? ;) Shucks...

That said, thanks for a) searching through the module swamp to find any existing efforts like this, and b) taking an initial stab at the code. Your description sounds very good. Now, if it wasn't 2am here and I actually had some energy to examine closely, I'd bother to download this, untar it, and take a look. ;)

Thanks again,
-Derek

beginner’s picture

4am?
2am?
what are you guys on?
It's barely 7pm, wednesday.

- fixed a big bug so that a form is actually showing on a comment page. ($intersect was called $intersection somewhere else).

one can't select 2 or more vocabs: only the form for the 1st selected vocab would show. I have not found the bug but if one selects several vocabs, only one form shows up.

-> about the general direction, I am still concerned that one has to post a comment to alter the taxonomy.

catch’s picture

Beginner - the only module I've seen that allows for reclassifying outside node edit is "taxonomy_switch" - which adds a form in a tab. Not looked at it in any detail.

We currently have to post comments for status/priority changes though and I don't think this is much different.

webchick’s picture

@dww, actually I wanted to do two separate attachments, but .info is not on the list, and I didn't have the brain space to go and change that last night in all the various roles. ;P

@beginner, thanks for the fixes! Yeah, leave it to me to change a variable name the second before I post a module. :P

Agreed, the "post a comment to change the taxonomy" is kind of a weird use case, which is another good reason not to include it in something like Community Tags. But it works well for project issue module.

dww’s picture

@everyone: All changes of substance on an issue should be logged and visible in the history of that issue. You want to see what changed, and when, even if it's just to bump/downgrade the priority or status. I think changing the classificiation of the issue via its taxonomy terms is equally important for everyone to see who made the change and when, even if it means older issues get "bumped" when they get classified. Classifying something *is* activity in the queue, so it makes sense that that would show up in your "Recent activity" view (my issues, tracker, etc).

@webchick: Didn't have the brain space for this, either, it seems: mv comment_alter_taxonomy.info comment_alter_taxonomy.info.txt ;) That said, yeah, we should probably allow .info files directly, assuming there aren't IE bugs that if you try to download a .info file it automatically reads it as a config file or something braindead...

Thanks to everyone working on this, it's great to see some help in the queue!
-Derek

aclight’s picture

I've modified webchick's version to:
1. Fix the problem where only one vocabulary was appended to the comment edit form (as identified in #32). The fix also adds the Categories fieldset when >1 vocabularies can be edited.

2. Added in submit handler so that taxonomy changes are saved back to the node.

I've lightly tested this and it works, but haven't done a thorough test.

aclight’s picture

@dww (and others): How do you propose that we present these taxonomy changes to users in comments (both on d.o and via email)? I'd like to work on a patch for project_issue that handles the taxonomy changes in comments, but I'm not sure how to best show these changes. What about multiple vocabularies? free tagging, multi-level taxonomies, etc?

webchick’s picture

aclight: Currently, we do this:

Category: bug reports » support requests
Priority: normal » minor
Assigned to: Anonymous » webchick

So I was thinking we could do one additional row per vocabulary, like:

Category: bug reports » support requests
Priority: normal » minor
Assigned to: Anonymous » webchick
Tags: banana, monkey, dishwasher » banana, monkey, dishwasher, spoon
Difficulty: Newbie, Intermediate » Newbie

Here we pretend "Tags" is a free-tagging vocabulary, and "Difficulty" is a multi-select, single-hierarchy vocabulary (what a mouthful :P). Basically analogous to the "Drupal version" taxonomy selector we have on things like book pages and forum topics.

So basically, comma-separate the selected terms, and put the before/after in same as we normally do.

The only place where this is going to look pretty ugly is something like:

Category: bug reports » support requests
Priority: normal » minor
Assigned to: Anonymous » webchick
Tags: banana, monkey, dishwasher, apple, pear, cat, dog, fish, silly, stupid, funky, funny, omgimsofunnylookatmylongtagwhichisgoingtototallymessupthistableomgwoowoowahwahwheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee » banana, monkey, dishwasher, apple, pear, cat, dog, fish, silly, stupid, funky, funny
Difficulty: Newbie, Intermediate » Newbie

No idea what to do about that. :P

dww’s picture

@aclight: Please see comment #24 above.

@webchick: Looks perfect. When people enter totally lame tags, we fix them. So what?

Thanks!
-Derek

webchick’s picture

@dww: Well. We can edit the crappy tag out (I just did so there), but the modified stuff gets pushed off the edge so you can't see what anything was actually changed to (at least in FF). But it's still in the src of the page somewhere if you really cared, I suppose. so probably not a big deal. Just figured I'd mention it. ;)

dww’s picture

To play along with your example, after the edit, either the issue's current terms or a subsequent comment will include the list of the sane tags that resulted from the modification. So, if you *really* cared, you could basically figure out what happened without even having to view the page source. But, this is a tiny, obscure edge case, no reason to hold up progress here worrying about it.

Cheers,
-Derek

aclight’s picture

In case anyone is curious, I've got this working on a test site. This depends on the patch in http://drupal.org/node/140473, so I'll keep this issue at cnw until that gets committed. The attached comment_alter_taxonomy.module implements hook_followup_metadata_changes() which determines the actual changes of taxonomy terms between followups (NOTE: this currently only works for free tagging vocabularies. I'll work on other vocabulary types next.).

The attached patch to project_issue adds a taxonomy column to {project_issue_comments} to store taxonomy metadata and pulls out the metadata to pass along to hook_followup_metadata_changes().

I've also attached a screenshot so you can get an idea of how these changes look. Feel free to make suggestions.

Taxonomy changes are indicated in issue emails like so:

-Status:       duplicate
+Status:       active
-AdminTags:    at1, at2, at3, at4444
+AdminTags:    at1, at2
-UserTags:     ut2
+UserTags:     ut2, ut3

test comment

beginner’s picture

The other patch is currently RTBC.

- do you plan to add support for any type of vocabulary soon (i.e. not only free tagging?)

- looking ahead, what comes after the patch: how does one query issues having a certain tag and that also correspond to other issue settings (e.g. critical bugs, for version X, related to component Y and having the tag Z)? Do we need a view (views.module)? or will the advance search form allow us to include specific tags in the search?

aclight’s picture

@beginner: I haven't quite finished this issue because I'm waiting until the diff/changes issue gets committed. But currently I have only written code to do taxonomy diffs for free tagging, but once I start working on this patch again I'll also incorporate diffs for regular vocabulary terms.

As for how to present and retreive issues tagged with certain terms, that's for another issue :) Probably this will require views. I'm not sure if it's worth it or desirable to try to add the search functionality into advanced search, but I haven't really given that much thought yet.

aclight’s picture

Assigned: webchick » aclight

Webchick mentioned an idea in IRC today that I hadn't heard before. My apologies if this is discussed somewhere else.

Once/if this patch lands, might it be possible to use taxonomy terms to replace the category, priority, and possibly status fields? This would make project_issue more flexible in that admins could add additional category terms, which is a feature request that we get fairly often. I just wanted to write this down in case it's feasible.

dww’s picture

Category and Priority would be easy fits for taxonomy. The one drag is it'd then be harder to translate the values. Maybe in D6 this is solved, but I'm not sure. Seems like http://drupal.org/node/115553 is a better place to talk about Category (and probably Priority, too).

Status would be harder due to all status-specific logic (row coloring, permissions, default queries, auto-closing, etc).

Component is out since that's per-project. :(

Assigned seems like it should be a CCK user reference field, not a taxonomy vocab. See http://drupal.org/node/85049

All of this has big link-rot implications, however, so we'll have to tread carefully...

dww’s picture

oh, and for more prior art on using taxonomy for some of these things, see http://drupal.org/node/85165

aclight’s picture

Just to bump this up a little, getting this issue finished first requires the issue at http://drupal.org/node/140473, and that issue requires http://drupal.org/node/200097. For those of you who would like to see free tagging on d.o, please help review these issues so that they can get committed to project issue.

Gábor Hojtsy’s picture

Go-go tagging! The current "only one category" system makes it hard to follow stuff. I am watching the locale.module and language system components for example, but when there are issues which are related but filed at other placed (eg. the module where they belong), then I cannot track them this way. I cannot track them at all. With multiple tags supported, this could all be much easier. Unfortunately I cannot offer any time to help in this :|

dww’s picture

Re the implementation details of #42. Hrm, I'm a little torn on that. :( It seems kinda yucky to hard-code support for taxonomy into the project_issue schema and codebase -- why have a generic hook and a separate module to deal with the metadata diffs if the data actually lives in pi itself? OTOH, taxonomy is core functionality, and I could see widespread applicability of it with project_issue, so maybe it's not so bad to just code this stuff into pi itself.

Anyway, either way, the logic/code/data needs to live in the same module. So, either:

A) Just handle it all natively in project_issue

or

B) Make comment_alter_taxonomy.module responsible for its own data to map taxonomy changes to comment ids/nids.

I don't feel *that* strongly on these 2 options, but the patch as it stands won't fly. ;) A) is better for d.o performance. B) makes comment_alter_taxonomy more generally useful to the rest of the world. Both have good arguments in their favor...

-Derek

p.s. Why "comment_alter_taxonomy" and not just "comment_taxonomy"? Just curious.

webchick’s picture

"p.s. Why "comment_alter_taxonomy" and not just "comment_taxonomy"? Just curious."

Because I'm sick and tired of ambiguous module names. :P

comment_taxonomy might:
- Allow you to tag comments with taxonomy terms
- Allow you to comment on taxonomy terms themselves, or on term listings
- Use taxonomy terms as comments
- Use /comments/ as taxonomy terms
- etc.

It's not clear at all that "comment_taxonomy" means "change the terms applied to a node by posting a comment", and since "change_the_terms_applied_to_a_node_by_posting_a_comment" is a bit long, I went with comment_alter_taxonomy. ;)

Sorry, that was unhelpful. :D I'll read the rest and respond more seriously in a moment.

catch’s picture

Quick note to say the administrative overhead of avoiding duplicate/empty etc. terms, which I remember being a concern when this first came up, could be helped by this module: http://drupal.org/project/synonym_collapsing

aclight’s picture

Status: Needs work » Postponed

I'm setting this to postponed for now, since I've finally created the comment_alter_taxonomy module sketched by webchick earlier on in this thread. That module is at http://drupal.org/project/comment_alter_taxonomy

It's still in progress, but I have it fundamentally working on my test site, at least as far as I can tell :)

For us to get free tagging or tagging in play, there's another issue for the project issue module that needs to get finished and committed so that term changes will show up in the metadata tables on issues. That issue is: #219734: Allow theming of changes in project issue table and email.

I'd be glad to have comments/suggestions on the comment_alter_taxonomy module over in that queue.

Even after I get comment_alter_taxonomy finished, there's still the issue of how to actually integrate taxonomy terms with the project issue module. Viewing lists of nodes associated with a term shouldn't be difficult, but as far as I know our current advanced search for issues doesn't have any integration with the taxonomy module. This is probably something that will be improved by #76725: Refactor project issue module to use Views.

sun’s picture

subscribing

aclight’s picture

Status: Postponed » Fixed

The Comment alter taxonomy module now takes care of this and has been installed on drupal.org. Therefore I'm closing this issue.

Status: Fixed » Closed (fixed)

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