Tagging

[aphenine]

When I was looking around the database, I noticed that the tag database obeyed a tree form, which meant that tags could be stored with categories and subcategories and so on.

This is not a feature that's implemented, and it's high on my list of "features I'd love to have in DW" (possibly no 1 :-) ), and I have also written some tree algorithms using HTML/PHP before, so I thought I might try to give it a go and see if it went easily. However, when I went looking, there are no bugs in bugzilla about tree tagging, nor does there appear to be any information about this as a planned feature, despite the DB support.

So, I was wondering, can any of you please tell me more?

Comments

[mark]

So, I don't use hierarchical tags. I've never maintained a community that uses them. You seem to take for granted a lot of knowledge that I personally do not have, which is hindering my ability to participate in this conversation.

I have no idea what you want these nested tags for, what you intend to do with them, how they make your life better, why they're needed, or anything. Which means that, technically, it's not really a good use of time to discuss implementation on something I am not convinced we need (because I don't understand what it is you're saying we need).

For most feature development on Dreamwidth, we go through a few steps:

1) The suggestion is made, which outlines exactly what you want the feature to do. This is typically done in dw_suggestions via the Suggestion Submission Form and then people can vote and provide feedback to refine the idea until there's a solid idea.

2) The idea is then approved by Denise or myself and put in Bugzilla as a new bug.

3) Someone who is interested in the feature then writes up a formal feature specification. This formalizes everything about a particular feature. For example, Denise wrote a spec for overhauling memories. That spec makes a formal plan for what a feature MUST do, what it SHOULD do, and what it COULD do (implementation and time permitting). With suggestions for UI, pages that need changing, things to watch out for, etc.

4) Denise or I approve the spec in Bugzilla. (Or we reject it with commentary and the author updates it and resubmits.)

5) Someone takes the bug and begins a technical implementation. This includes what you're writing here; the technical spec for the implementation plan formalized by steps 1 and 3.

6) The implementor uploads a patch and requests a review.

7) The review happens. If it needs more work, the patch is rejected and the submitter has to update it with the feedback from the reeview.

8) The patch is committed.

9) The feature goes live.

So, from my point of view, you're jumping straight to the 5th step, and I am not clear on the first four steps. I don't understand this feature you want, what you want to do with it, and therefore I cannot judge whether or not the technical implementation you are proposing makes any sense.

Make more sense now? If you really want nested tags, then you should start at the first step. I promise it's not as painful as it sounds, and the feature will be much, much better for it. :)

[aphenine]

I'm sorry. I know about dw_suggestions and the suggestion process. If I'd known that I was proposing a completely new system, I would have gone through the established channels. I'm really not trying to short circuit anything and I really thought it was a developer query given that there is already support in the database and I was confused.

[mark]

Oh, don't be sorry! It's totally fine. If there were more than five lines of code and one database column, then you might be on to something. But really, there's not much support in the code for nested tags. Even if there was, we'd probably still at least go through everything from step #2. (We sometimes skip the suggestions process, but almost never skip the spec process.)

[cesy]

Can we get this put in Bugzilla, and then one of us will do a feature spec? Proper nested tags would be very useful.

[mark]

If you want to do so, go for it!