Provide a mechanism for issue meta discussions

I'm generally opposed to such a change, but that might be because I'm so used to the way it currently works... Here's why I'm not in favor:

A) This does *not* integrate well with death to subscribe comments. On the contrary, it would become much harder to follow an issue via email, since either you'd have to get somewhat confusing emails with the diffs whenever someone edits the original post, or you'd miss all of those edits entirely. Whether or not people can subscribe to get notified about changes to the issue without commenting is orthogonal to how users actually record real changes to the issue.

B) I'd *hate* it if any random user could edit my original issue post (text and title) so that people newly reading an issue would assume all of that text was written by me, unless they went out of their way to view a history/diff tab. In fact, the proposal here would be a step even further away from #151984: display the initial issue metadata with the initial issue post which I still think would be useful to do.

C) I think it's a lot more clear to follow the history "in-line" than to have to toggle back and forth between different pages to see what's being changed when, by who, and why. E.g. I add a comment #54 just after I edit a few meta data fields, you'd have to look at the top of the issue to see the values, look at my comment a few pages down to see what I'm talking about, and have the changes/diff tab open to see what I actually changed. As it is now, you see all of that at once when you read my comment #54.

D) I think it'd be a lot harder to make sense of collisions during "cross posting", e.g. multiple people trying to edit an issue at the same time. Again, this issue takes us further away from #218066: Prevent cross posting from reverting metadata fields which should happen.

Therefore, I'm inclined to mark this "won't fix", but I'll leave it open for further discussion since I'm definitely sympathetic to new perspectives on the usability of our issue queues and how to make them better.

Note that I think there are a lot of ways we could improve the current UI to help address some of the problems brought up here that don't involve such a radical change to a wiki-based issue UI. I'd be more than happy to discuss, review, and commit such changes in other (self-contained) issues.

Thanks,
-Derek

I'm sympathetic to the problem that comes up, especially in long issues, in which the original issue may have little to do (or perhaps be outdated or incorrect) after many comments have been posted, and so for someone new to the issue it takes a fair amount of time and synthesis to be clear on what the current state of the issue is. But as dww said, I think the proposed change would be a change for the worse in most respects, especially for people who are already following an issue and are familiar with its current status.

Just to be clear, by status, I don't mean "active", "fixed", etc. but more what parts of the issue still need to be coded, etc.

Me in #587316: Let's try wiki style issues:
Both in Paris and on a certain recent blog post this bubbles up as a desired thing to at least *try out* as a first step towards improving our bigtopiccollaboration tools. Architects make *big* drawings you know. Let's try the wiki canvas?

Right. Reading Crell's blog post on the topic helped clarify why this could be a good idea. I'm less opposed now as I was when I wrote my previous comment here. I still think it'd be ideal if it was optional -- sort of like "discussion" vs. "wiki" on d.o, which means that we'd need to make project_issue more CCK + field friendly, so you could specify multiple content types that acted as issues. That'd be a very good thing to do, anyway...

But yes, let's keep discussing exactly how this could/should work.

Thanks!
-Derek

I'm sort of beginning to think of this less as a wiki and more of how i would go about organizing information that was contained in 300 comments. I think this thingy would resemble the wiki in that it is a living document, but i think that having a bit of structure would be a good thing.

Here's a brain barf of information i think that wants to be organized in a living document.
2. Reasons the some people think the patch is a bad idea (crossing out points that are addressed)
3. Reasons people support the patch.
4. Related issues/dependencies
5. UI mockups/screen shots
6. ToDos (stuff that needs to be figured out, or done before the patch can be considered for inclusion)
7. Examples of how people might use this code everyday (particularly important for api additions/changes)
8. Related links -- technical docs, discussion, etc..

We want to keep the current ifac system. It's good. We also want that the original author be able to be able to transfer node ownership http://drupal.org/project/edit_authoring_info (needs upping to D6, but it's very small) and the node owner to grant http://drupal.org/project/shared_edit edit access. This way we have a blissed mix: anyone can edit who the owner thinks has something useful to say but not every newbie who stumbles on the issue: they can comment.

You know what, Edit Authoring Information would be useful for projects as well so that people can transfer their projects as they wish without webmasters involvement. Of course webmasters would be still needed to transfer an abandoned project but it's still useful.

Sounds like a 'by invitation' pyramid. I can see that there needs to be some handling on the 'everyone can edit' and this might be a way to go about it.

Similar to what I think Nick suggests I feel there's two sides to this: collaborative wiki && smart topical aggregation. Let's explore a bit more.

Concur with chx's thoughts on this -- the ability to grant additional people editing rights for the issue itself is (IMO) as far as we'd want to go. Commenting on the issues would still be open to anyone, but a trusted circle could continue to update the node itself to keep it in sync as a high-level overview of a battle plan or portal for related and mutually dependent issues.

I think it's a lot more clear to follow the history "in-line" than to have to toggle back and forth between different pages to see what's being changed when, by who, and why.

dww, I can definitely see what you mean here. The discussion that was put forward at the Paris meeting did NOT include anyone advocating the transition of all project issues to this format. In fact, the idea was to create a separate content type with this wiki-esque behavior that would focus on aggregating and outlining plans, then linking off to relevant issues.

Right now we see that model being used in Webchick's 'community initiatives' pages, summarizing groups of related issues and what the gameplan for them is. We see it in #509404: Fix some conceptual problems with install profiles and make them actually usable, where there is no actual issue, just a battle plan that links off to other issues. And we see it even more frequently in the UX work, where large-scale vision/meta-issues get posted in a single issue, and immediately die in a flurry of minor tweaks with no clear way to split off sub-issues for implementation.

Ultimately, it's about the lack of a good place on d.o.'s project infrastructure to capture meta-issues and the discussion around them. There was a pretty strong consensus from both developers and designers present that it's a really serious problem, and I think that there are definitely some ways we can work to solve it. You're definitely the expert, though, on the workings of theproject infrastructure and I'm not sure what the implications are for the rest of the system should we put something like this in. Do you have any thoughts on the basic idea -- Add a new content type that is editable by selectable, trusted users, contains links to related sub-issues, and is intended for architectural/battle plans/proposal overviews?

Better title based on how this conversation is going. Some thoughts on each approach:

Leave the existing project_issue node type as-is, and add some other node type to be the "issue meta discussion wiki page"

A) What does this node type need beyond a title, body (with d.o issue link filter enabled), file attachments, wiki-esque edit perms, diff module, and comments enabled? If that's it, what's wrong with d.o book pages? Don't those *already* meet all of the above requirements?

B) Do they somehow know what project they belong to? If so, what about meta issues that span multiple projects? Do we just need to revive #87052: Allow forum posts to be tagged with Project taxonomy terms and have a vocab on d.o that automatically has a term for every project on the site, and then give these nodes an autocomplete text field to tag them with projects? Alternative, if all projects on d.o were OGs, wouldn't that be a perfect way to associate these meta wikis with specific projects? Easy answer to "how to cross-post to N projects." There are also various interesting ways to handle the "who can edit these?", but that might be getting too far ahead of myself. It'd also be an obvious answer to "should anyone get email notifications about these wiki pages?" -- yes, depending on their OG configuration...

C) Do they need a status field? If so, how is it altered and how do you record the history of changes? Seems like "No" is the right answer.

D) Do we want full wiki editing to all d.o users, or do we want restricted access to edit in some way? Full editing seems to work on book nodes -- not sure we need anything more complicated here.

E) How would people find these wiki pages? Would we want them to somehow show up in the issue queue views? Would there be a block on project nodes with a view of these things? Depends a bit on the answers to (B). Is there just a section of the handbook for these things, organized by some sort of hierarchy so people can drill down to find what they want, assuming that all we're really talking about is more formally embracing the "Community initiatives" concept and solving this problem via book nodes.

F) Related to (E): Do the issues that are referenced in a meta issue know about that and somehow link back to their meta discussion(s)? Seems like it could be nice, but would actually complicate things quite a bit, so I'd probably vote against such a thing, at least not in phase 0.

provide a way to give out edit access to the original post on certain issues

G) How would email notifications work? Would people subscribed to an issue queue only get email when the thing was first posted, or on every edit?

H) Who has permission to give out edit permission? Just the author? Anyone who's already got edit perms? Everyone with CVS access to the project the issue belongs to?

I) What could you actually edit? Just the body of the original post? Probably attachments, too. What about the issue metadata fields? My preference if we went this route was that any changes to the issue metadata would still require a comment like they do now.

J) Would these things somehow show up differently in the issue queues? Would we just have a convention about the title or something?

I'm totally in favor of the first approach. I've often used wiki pages on g.d.o for meta stuff (e.g. release roadmap nodes) since they were wiki-able, but hated the fact I couldn't use the d.o issue nid filter (e.g. [#569552]).

I'm a very strong believer that d.o projects should just be OGs -- I think that'd solve all sorts of problems, and in that case, there's an extremely obvious solution to basically this entire issue. However, that continues to be stuck on a few infra team and d.o redesign hang-ups -- e.g. folks don't want to run OG on the "main" d.o, but we don't have a "downloads.d.o" subsite yet, etc, etc. Ahh, the joys of trying to get things done on d.o... ;)

So, until all that happens, I'd be happy with just making better use of book nodes for this as a short-term measure that requires no changes from the infra side. Alternatively, I'd be happy to see #87052 solved (which could be useful for other things like case studies, security announcements, forum posts, etc), define a new node type just for this, and create some views to find them.

I'm less excited about the "conditionally wiki-ify certain issue nodes" approach, since I think it's more complicated, and less flexible in some ways (e.g. there'd be no good way to cross-post such a meta issue to multiple projects if needed)... But, if there were compelling reasons that actually made it better than the separate wiki node type, I'd still consider it.

A: The problem with anything that is not part of the queue is that they're not part of the queue. We've seen it with brainstorm discussions on gdo, we've really seen it with the d7ux project site: any plan or proposal that is prepared outside of the queue will be torn down and re-done again once it appears in the queue. We want to try and prevent that from happening with the approach we come up here.

B: Can't say for sure, but I guess yes, these discussions could span multiple projects and should be tagged as such in some way. I know I really liked the idea of projects being OGs when it came up, and still do.

C: I think we can do without a status field for a start.

D: Because we want to make these part of the actual queue I suspect we want to restrict access similar to what chx and eaton describe.

E: Like my A, I think showing up in the queue is essential. All good questions about how. Need to chew on that a bit and would like to hear how others envision this.

F. Agree on that being a nicetohave, not a musthave

G. Can't say, don't use them

H. Just the author seems like a very restricted place to start, since I'd expect these issues to be started based on discussion between multiple parties. Though the initial author would probably grant her partners in crime edit rights immediately. Everyone with CVS acces to the project seems arbitrary, we can't assume those are the people that want to start such a discussion.

I. If we make a log message required on wiki edit, could we show that as a comment?

J. Yes to looking different. Naming convention only seems fragile. Related to E, needs thought and ideas.

I think "conditionally wiki-ify certain issue nodes" is out of the question indeed.

I second @eaton's observations from #8. The community initiatives section is something I've also been trying to use for some stuff, but ultimately it is very much disconnected from the issues themselves. The listings are not interconnected with the issues, so when you open a follow up issue or side issues on an issue, unless you specifically know that the issue was on a community initiatives page [edit: and you go there to update it, the overview is quickly getting outdated].

Here's a hybrid approach between dww's and eaton's/yoroy's:

A new content type (but enabled with project taxonomy and/or book module), which has a multiple nodereference field so that you get a proper connection between it and the issues themselves. For extra bonus points that content type has a view at the bottom with all the referenced issues in a nice table like we have now on the main issue queue listing. Otherwise the same as a handbook page.

Then we add a tab or block on issues, which lists any meta-discussions they're referenced from, possibly with an option to create a new meta-issue if one doesn't exist. That way there's no project* specific code involved, but still some feeling of connectedness. For extra bonus, some way to link issues back to meta-issues without having to go and find and edit them, but that's probably not such a big deal.

And count me as another person who tried and failed to use community initiatives, posting diy meta-issues in the queue and linking off in followups is a lot easier to track, and also they get bumped up in the issue queue instead of rotting.

Actually, F (child issues linking back to the meta) is quite important after all. How else will the unsuspecting contributor find out about the larger context this specific issue fits in? Some indication of "this is part of a larger thing" should be in there. We do it now by manually putting in a link back to the meta issue. This may or may not suffice for a first phase.

Re: #14 - the advantages of having a real reference are huge. Its not very different from the classic dependency features we find in dedicated bug tracking software.
I like the idea of a "Roadmap" node type which issues reference as the highest level in the hierarchy.

For example:
-------------------------------------
Make Drupal Cool Roadmap
Tags: UI, Theme, Design

I wantz drupal to lookz cool. Lets put lots of cool looking features in teh drupalz.
(lasted edited by: inoobish 6/06/06)

***
Completed Issues: (back references from issues that are committed)
#342145 Ajax, flash, and stuff

Pending Issues: (back references from issues with a patch)
#453466 Make Drupal look likez flickr
#453256 Social tagging tagging

Open Issues: (back references from issues without a patch)
#453466 make picture of attractive female deliver all error messages

----------------------------------
A few things to point out --
1. i think this being populated by live backreferences makes the document infinitely more useful. Imagine if we had this for D7UX!
2. this document could be built totally organically, or be the work of one. For example, when Chx added all the test coverage issues, he'd reference this roadmap.
3. the node reference system could perhaps allow for multiple levels here. Lets say "enable taxonomy to categorize anything, not just nodes" referenced "#453256 Social tagging tagging". perhaps the pending issues section could look like this:

Pending Issues: (back references from issues with a patch)
#453466 - Make Drupal look likez flickr
#453256 - Social tagging tagging
**#153252 - enable taxonomy to categorize anything, not just nodes
**#123422 - make taxonomy api useful

I realize that example isn't conceptually sound, but it i think you see what i'm getting at in terms of how a self building roadmap could be useful.

Although a multi-valued node reference field would be nice for automated cross linking, there are a few problems:

K) That'd mean installing all of CCK and node reference on d.o, which might hit some push-back from killes and others on the infra team.

L) Then there's no way to order the issues, annotate them, group them under headings, etc, in the wiki page itself.

Instead, maybe we want a bit of code that just maintains a DB table of [#nid] references by nid. Via nodeapi on 'update' or 'insert', we do a quick preg_match() to find all occurrences of [#nid], and insert those into a new DB table. Then, we can still do cool stuff like when viewing any issue that's referenced by a metawiki, we create a block or some stuff in the header at the top or whatever, that points back to the meta wiki(s) that references the issue. We could trivially expose this table to views and add a field on the issue views with a little icon or something when an issue is referenced in any meta issues...

Also, can everyone please be specific about three different things:

M.1) What you see when you directly via an issue node (e.g. http://drupal.org/node/569552)
M.2) What you see in the issue queue listing (e.g. http://drupal.org/project/issues/project_issue)
M.3) What you see on the project page (e.g. http://drupal.org/project/project_issue)

When you advocate "meta wikis need to show up with the issues", are you talking M.1 or M.2?

Thanks,
-Derek

Derek, to be honest, i wouldn't advocate CCK node reference to the task either. What we need here is a pretty clear cut NID -> NID relationship that's easy to query without views. I fully advocate project module defining its own schema instead of pretending that CCK nodes really can package themselves in the same way (we're close, but not really there at all)

Actually, for all practical purposes, i'd be perfectly fine with "road map" node types being defined hook_node_info(), and all extra fields being contained within the a project module schema instead of CCK (ducks as rotten fruits, vegetables, and livestock are thrown at him).

Anyways,
M.1. Probably a line referencing a road map in this gizmo -- i think this feature basically is "issue tags 2.0" and would be in favor of replacing them with roadmaps.
Project: Project issue tracking
Version: 6.x-1.x-dev
Component: User interface
Category: feature request
Priority: normal
Assigned: Unassigned
Status: active
Issue tags: d7ux usability, drupal.org redesign

M.2. Probably very few changes if any. Again so many simple projects work within the given framework that i think we should "add features" for the most part, and not change them. (at the very least for the purposes of getting this improvement off the ground).
M.3. If a project has a roadmap, maybe a listing of the most recent, similar to the way versions are listed.

Stuff i really want to throw into the mix:
1. Roadmap node type in project module
2. Ditching node reference as an option in project module, and instead going with a native node to node association system. This seems easier, and frankly more practical since our goal isn't to do "whatever" with node references.

** edit ***
I think the relationship is issue to roadmap, not roadmap to issue.

Issues care about what roadmap they link to, roadmaps don't give a rats ass.

The references between issues are simple, at most i could see a reference table containing (not advocating this)
source_nid
target_nid
type
weight

The nodes themselves do the rest of the dirty work. If an issue's status goes from needs review, to fixed, we update the issue node, therefore the roadmap nod gets updated (sine it merely feeds in data about related nodes, it doesn't actually define stuff like "code needs review".

An aside, dww and yoroy are building a ghetto prototype.
http://drupal.org/node/569552#comment-2081706
http://drupal.org/node/569552#comment-2083800

Note alphabetical order. I only noticed cause I saw K + L + M -- and got paranoid that dww was maybe suggesting the idea was like this: http://www-tc.pbs.org/wgbh/nova/planecrash/images/minu-tenerifecrash7-l.jpg

Something that's also occured to me (but i haven't really pushed it because i understand the difficulties) is adding running items to a some category in an issue. "add a protest", "add an example"... etc... I think its worth exploring, but it is pretty far outside of the current box were working in.

Note that while #6 is not too grandiose it has a distinct advantage: it can be here and now with minimal effort. More can be added later...

@chx: KISS applies more strongly to a simple new node type (or just using book pages). All this auto-reference stuff is where everyone's trying to complicate this beyond deployable in less than 4 hours. I think it's reasonable to brainstorm the goals as we talk implementation details, but that doesn't mean I think we should attempt to implement everything at once. 10.A and 10.B is perhaps all we need (at least for now), and would be as easy as porting your proposed modules to D6, and would potentially help for other d.o needs...

@Nick Lewis: Project* is full of code where "we" implemented our own special case of something instead of using other modules that provide the same functionality. The result is a very large code-base that very few people maintain or contribute to. In general, I'm trying to move it in the other direction (e.g. using views instead of custom query builders, etc). There have to be some very good reasons we need to do our own thing before I think it's really a good idea. I don't think my comment #16 is necessarily sufficient to justify our own node reference system, I was just putting it out there for consideration. ;)

It *is* analogous to the kind of issue node reference system we're going to want for CVS commit messages, so that issues automatically know the commits that reference them via "#nid" (e.g. to have an auto-generated block on M.1 issue nodes listing all the CVS commits that reference that issue). And, there's no way we can solve *that* problem with CCK. That's why it was on my mind as a possibility to throw into the mix.

p.s. Re K, L + M: Those letters were just the continuation of my points from comment #10. I tend to do it like this in long issues so that it's easier for people to reply to specific points in followup comments.

+1 subscribe! :-)

I would actually favor the meta-issue node type referencing to the issue node type. Let the meta issue control what its branches are, otherwise any time someone drops a [#] into a comment they'll get extra links showing up. That's not "this is part of this meta issue", it's just a "possibly related issues" block. (Also potentially useful, but that's something else.)

I think that's important to make a distinction about. What we talked about in Paris is not a related-issues system, but a "this issue is for big picture discussion" vs. "this issue is for arguing about whether to use a foreach or while in this particular case" split. Right now we lack that, and it means the former gets drowned by the latter, which sucks for all involved. Dependent issues should absolutely be a curated list, not a "these 50 issues happen to mention me" list.