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: Provide a mechanism for issue meta discussions).

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.

#651484: Enable CCK and node_reference

What is a "meta-issue linking to other issues"?

Is this a meta-issue?

http://drupal.org/project/issues/search?issue_tags=FilterSystemRevamp

Does it have a title?

Yes.

Does it have an editable description?

Yes. But we neither display it, nor do we allow to edit it.

Could we even commit on it?

In D7, yes, when http://drupal.org/project/comment_field has been created (something I want to work on)

@sun:

Can we prioritize issues there (beyond having three priority levels and then arbitrary ordering of issues under those)? No.
Can we order issues into a tree structure to signify subtasks, breakout issues, etc? No.
Can we add further descriptions to issues for the overview to help understand the context beyond sparse issue titles? No.

These missing items resulted in the community initiatives summary pages to be born (see http://drupal.org/node/362922 for a use case of how these are applied). These pages however do not allow for much discussion or collaboration and can be tedious to maintain with the issue queue changes. So issue tags solve some of the grouping issues, but to have better overviews of the problems in many cases, a simple list of issue titles does not cut it.

#623326: Design all interactions for customizing dashboard contents is an example. It's a pain having to backlink each issue manually and still people won't see it because it's in a comment somewhere up there.

Linking this from the Redesign project #661692: Meta issue for modules Project and Project issue tracking because this issue was tagged 'drupal.org redesign'

;)

Right now, the comment interface is really confusing because it's part editing the issue and part adding stuff to the discussion. Those operations could be more isolated.

I believe the opposite is true. By having every change be part of a comment, we get a unified timeline interface. You gain the possibility to read all of the issue in a linear way, as opposed to jumping around between different resources.

I think the big problem is signal to noise: The relevant information is hidden between loads of either irrelevant, outdated or redundant comments. What we need is comprehensive and frequently updated summaries that are easy to find when reading an issue.

Updating the summary (or writing a new one) needs to be part of the usual process of participating in an issue, or otherwise the "frequently updated" is a pious hope.

This is why I don't believe in summary or wiki pages or meta-issues that live outside of the issue itself.

--------

Some ideas:

1) #682254: Allow multi-dimensional rating of issue comments
Why?
+ Filter Signal from noise in issue comments
+ Make it easier to find important patches or summary posts, and allow to skip the rest.
- It does not reflect relations between arguments.

2) In addition to the original issue text, have a free text field that can be edited by everyone, and that can be used as a summary. This summary text could be displayed on top of the issue, or at the bottom. Every change to this text will be associated with a comment, with a (collapsed, or visible on mouseover) changeset overview.
EDIT: See #32 (rfay) point 1, "issue summary field".

3) To reduce noise, changeset-only comments with no actual comment text could be given a smaller display footprint, and be marked as such in the issue tracker page.
EDIT: more general: heuristics to identify "minor comments" (for instance, if they say nothing but "subscribe").

EDIT:
I think categorization and rating of comments would be the most useful of these ideas.

Related issue: #648218: Make API changes in Drupal core be nodes

We're going to be working on this at Drupalcon.

sub (oh wait, death to subscribe comments)

I'm working on a related issues module at http://github.com/shomeya/pi_related that could help with this issue.

Since #651484: Enable CCK and node_reference is postponed on this… Most comments up till now are about that yes we want this.

Now lets try and get more concrete:

- Which tasks/goals does this want to facilitate again?
- Come up with a spec for the first version of this new content type.
- Define the basic workflow(s) associated
-…

(bump to self…)

Here's a low-end proposal:

IMO the bottom line is that every issue needs an issue summary and links to related nodes (dependent, dependency, related).

So:

1. Add an issue summary field which can be edited during comment edit. We do this with taxonomy terms now, we should be able to do it with a fieldset-enclosed issue summary. Edit: This should always include which patches have been committed.

2. Add nodereference for related nodes (not just related issues: We can point off to areas like the initiatives, etc.) Allow these to be updated in the comment workflow.

3. Change the status settings expectation to require a decent issue summary before an issue can go RTBC.

This very modest approach would deal with so many of our problems in this area, but it is not intrusive and does not require much of a workflow change - just provides a lot of new tools.

These two things are a very modest change to our workflow

I appreciate yoroy's constructive bump, and I really like rfay's proposal in #32.

My only questions/concerns:

A) If we add an issue summary textarea to issue nodes and allow those to be edited via comments (great idea!), how do those edits appear in the comment? Do we store each edit of the summary as a new node revision of the issue, and the comment's table of issue metadata changes just says "Issue summary changed" which is a link to the diff of the issue node? (We're already running diff.module, so that'd be pretty easy).

B) Aside from the obvious UI for the multi-valued "related" node reference field (e.g. the current values appear under the issue metadata table in the original post, and you see +/- for specific nids on any comment that changed the related nodes), should we add any other UI to display these? E.g. on every node on d.o do we have a "related" block that conditionally appears which lists all the issue nodes that point to it (if any)? Views can trivially provide such a block. If we're doing this, do we want to split it out into separate node reference fields for "related" and "dependent"? We could then display a "dependencies" list automatically as the remote block. I think it's a bad idea to have separate "dependent" and "dependency" fields -- everyone should just point to the things they depend on, and the parents can automatically display lists (potentially even trees if we want to get crazy) of dependencies.

I'd also like to hear from mikey_p about http://github.com/shomeya/pi_related and how that could fit into proposal #32.

Thanks everyone!

Cheers,
-Derek

Do we store each edit of the summary as a new node revision of the issue, and the comment's table of issue metadata changes just says "Issue summary changed" which is a link to the diff of the issue node? (We're already running diff.module, so that'd be pretty easy

That sounds perfect to me.

I do think we'll want to use views to show dependent and blocking, and other related issues. And I agree, it sounds easy enough to do.

#27 (myself),
#32 (rfay),
#33 (dww):

issue summary field which can be edited during comment edit. [required for RTBC]
-> yes, could be useful.
-> for trivial contrib issues it should be sufficient to write a very short summary..

nodereference for related nodes
-> is this really necessary?
-> we could extract this information from comment text instead, using backlinks / "what links here" (available in views 2). We just need to fix this issue first: #205202: Fix search index link handling for non-existent nodes.

rating and categorization of comments by readers
-> has not been picked up in #32 and #33, but would really help a lot.
-> a well-designed multi-dimensional rating could provide both rating and categorization.
-> imaginable categories / rating dimensions: patch, symptomatic problem description, debug analysis, explanation of existing code, good idea, plan for implementation. The point is to easily find those comments one is looking for, and skip those that are less interesting. Especially when reading an issue the 3rd time.
-> rating would not say "i like this", but "this post adds value to the discussion, something that has not been said before in this way".

Summary field and node references are solutions to the problem at hand. Not sure if "just fixing" a 2.5 year old issue sounds convincing to me :-) I can't discuss what the best choice code-wise would be but being able to referene other issues in a simple way is at the heart of what this is about. Not sure what you are questioning though: referencing nodes at all or using nodereference to do it?

Ratings and categorization are something entirely different imo (and ratings are experimented with on g.d.o right now, we'll want to learn from that first). Thats reputation management. I'd rather see the summary being groomed, tweaked, improved continuously. Lets keep the scope focussed on getting ourselves a bigger canvas to draw on than the current 'issue' format gives us.

Not sure if "just fixing" a 2.5 year old issue sounds convincing to me :-)

The only reason why this issue is not rtbc is a small disagreement on variable names and comments. I didn't feel like spending more time on this, because I had more interesting things to care about. But technically it is as good as fixed.

Not sure what you are questioning though: referencing nodes at all or using nodereference to do it?

I think if we had a decent "what links here" feature, we would not need the added form complexity of a dedicated nodereference field. I'm not totally opposed to it, I just imagine that "what links here" should be considered as an alternative.

Ratings and categorization are something entirely different imo (and ratings are experimented with on g.d.o right now, we'll want to learn from that first). Thats reputation management.

Reputation management is only one aspect of this, if ratings are summed up for each user.
In this discussion I'm not really interested in reputation management, but rather finding the useful comments in a long list of noise. stackoverflow.com is a wonderful example. The reputation aspect on stackoverflow is only a side effect, the most important thing is that good answers are on top.
I would not suggest a clone of stackoverflow, but rather something custom-tailored to the nature of d.o. issue discussions. Reputation management can be a part of this, but I would suggest to be very careful with this.

Comments are often more important than the topic starter, so I think they deserve at least as much attention.

The issue title ("provide a mechanism for issue meta discussion") is quite generic imo, so I don't think this is off-topic.

ratings are experimented with on g.d.o right now, we'll want to learn from that first

ok ok...
I think the debates on groups.d.o are quite different in nature. I did not spend much time there yet.. I want to get things done.
Maybe it makes sense from a technical point of view to learn from g.d.o. rating mechanisms. From a design point of view, we can just as well look at stackoverflow or similar places, which work successfully for quite some time now.

And in the end, as said, what works for stackoverflow or g.d.o. isn't necessarily the best for d.o. issue discussions.

I'd like to not get this issue derailed by the whole rating/reputation controversy. There's great value in that whole conversation, but it's a way to grind anything to a halt. I would be very happy if we just accomplished:

1. An issue summary
2. Related issues/related nodes.

Ok, thanks for the explanations. Lets agree to keep ratings etc. out of this for now, here.

'What links here' sounds like a more automated process than nodereferences? I *think* I would like to manually manage things a bit but might well be fooling myself there. Would like to hear other peoples thoughts on this.

There are a couple of mockups lurking in dww's comment #33. I'm happy to draw them but can't fully parse what's being suggested there yet :)

summary
Review & critique comments #32 & #33 :-)

Ok, I'll stop with the comment rating stuff. Anyone still interested in this can go to the other thread on comment rating.

The other controversy (not really a conflict, just an alternative I thought worth to consider):
dedicated nodereference vs "what links here" extracted from node and comment text.

The arguments:
* Dedicated nodereference would make the interface one step more complex, and needs people who care. (just think of taxonomies, only a few people care to add tags to an issue)
* "what links here" would work with all the existing links in existing issues, with no extra manual work.
* Dedicated nodereference does not give any context to issue references, unless we add a description text field (not sure if we want this).
* "what links here" needs a patch to work bug-free. It's almost rtbc, but so far noone wants to fix the comment issues (yes, I'm lazy).
* I'm not sure atm if "what links here" searches in comment text. If it does not, we would need yet another patch or new module for that.

@donquixote: For the sake of the d.o DB servers, we want dedicated node reference fields holding integer nids, not text search. We will then be able to make trivial blocks to display the dependency and relationship graphs of issues automatically and relatively cheaply. Having to constantly search all the text of all comments on d.o would be a performance nightmare.

Furthermore, I think most of us want more specific control over the referenced nodes. They shouldn't appear in a list at the top of the issue just because someone happened to mention something unrelated. There should be a record of when a reference was added/modified, and I think we're going to want separate fields for "related" and "depends on". Just like the issue summary that everyone is constantly working to improve, we want the set of referenced nodes to also be edited and refined throughout the history of the issue's discussion, not just a giant unwieldy pile of everything someone mentioned.

Re: "some comments are more helpful than others", people could mention and easily link those specific comments in the issue summary. E.g. if you write:

#569552-33: Provide a mechanism for issue meta discussions

You get:
#569552-33: Provide a mechanism for issue meta discussions

which links you straight to my last comment (#33). We could even fix up the display logic for the [#] text filter so that if it's rendering on the issue itself, instead of the above output, you'd see something like:

Comment #33 (dww)

@yoroy: For the comment form UI, I think we're just talking about adding more fields to the "Edit issue settings" fieldset above this comment box I'm typing in, or adding two new fieldsets just like it (perhaps those two should be collapsed by default). One says "Edit issue summary", and the other says "Edit issue references" (or something). The first just holds another textarea for the editable summary. The second holds 2 multi-valued node reference autocomplete textfield widgets, "related" and "depends on" that let you type nids or titles.

Re: #44162: Relationships between issues: support for parent issue and related issues we could make it so that the Edit issue references auto-expands whenever you mark an issue in a status that implies a reference (blocked/postponed, duplicate, etc).

The only other mockup would be the top of the issue page. I was just imagining some nicely formatted node ref links with the appropriate headers, much like the issue tags now. Then, below that table, there'd be the "Issue summary" header and the current value of the summary, then the existing "Description" header and original post, which perhaps should be renamed to "Original issue" or something. That'd also help the UI for #151984: display the initial issue metadata with the initial issue post...

Let me know if that's clear enough to start from.

Thanks,
-Derek

@dww (#41)

Playing devil's advocate a bit. Not because I want it so much, just because I think we have not thought this direction to the end.

Having to constantly search all the text of all comments on d.o would be a performance nightmare.

The backlinks search only happens when a text is saved, searching exactly this text. The results are cached in a big table. There could still be some overhead somewhere though, not sure about this.

Furthermore, I think most of us want more specific control over the referenced nodes. [..] we're going to want separate fields for "related" and "depends on".

This could be done with meta information in the text. Something like <a href="..." type="dependent">...</a>.

They shouldn't appear in a list at the top of the issue just because someone happened to mention something unrelated.

Which could be done if we only look into the issue summary for backlinks, or give these links higher weight.

--------------

One problem we will have to tackle, if we introduce summary field + nodereference, is the size and complexity of the comment form:

I did this on a test project myself some time ago, using Comment CCK (going to be abandoned, use Comment driven instead). (btw, funny that noone has mentioned these projects before)

The result was a huge beast of a comment edit form. Especially, it was no longer intuitive which textarea is the summary field, and which is the comment text. Yes I know there is a label, but most people (and myself, especially) just want to go to the first big textarea they find and start typing.

To those who think people are smarter than this, just think of all the people who change the issue title because they thought it is a comment title. Or think of accidental issue status changes.

Maybe it is ok if we make the issue settings collapsed by default, or a part of them.

-----------

The other question is, where do we display the summary text? Below the issue starter? Or repeat it somewhere in the bottom, after the last comment? I think the first would make the most sense.

On the nodereference fields, if we have a 'depends on' field, it'd be good to show the backreference in terms of display - so issues would have both "depends on" and/or "required by" lists shown.

I'm not sure how useful a second nodereference for 'related issues' is. We already have issue tagging, and if we want a block like that, I think the apachesolr one might be better - apachesolr.module provides the block already, the results are very good IME, no additional MySQL load, and that'd help for finding potential duplicates too.

The summary should likely go above the opening post, then everything below is chronological.

Hi all, I have written a small module with this problem in mind, at http://github.com/shomeya/pi_related and I'll try to move that to Drupal CVS as soon as possible. It was written not using CCK in order to provide a simple form that could be enabled on an issue for anyone to use to modify the related issues. The design is basically copied from that of the Redmine issue tracker for Rails. (Something that gets great reviews from many software development folks...) It was designed with a few use cases in mind:

#43: This module doesn't use CCK and stores the relation in such a way that there is no difference between a forward and backward relationship, it is a single relation and is displayed on both issues.

#42: The Related Issues module does not use CCK so that the form is not part of initial creation, or not part of issuing a comment followup.

#41: The module also allows multiple types of relationships to be defined (blocks, related, duplicates). This could possibly be modified to work alongside the status field, and prompt the user to save a related issue when using certain issue statuses. Also, this module doesn't store it's historical data along with comment followups do to the synchronous nature of the relations. Each relation would cause two comments to be created, one on each node of the relation, which could lead to additional issues with cross-posting, etc.

I'm open to making whatever changes need to be made to get his module working on drupal.org and I had drupal.org in mind when I begin designing the module as well.

@mikey_p, I seem to remember you had a screencast of this or something, perhaps you could post that. Alternately, perhaps you could make an installation of it available to this group (or dww would let you put it on scratch). It's much more likely to generate the enthusiasm it deserves that way.

Sure, watch a short video at http://blip.tv/file/3608859/, and I'll try to setup a test site soon.

Edit to #32: The issue summary should always contain a statement about which patches/comments have been committed. Perhaps this should be its own field, but just getting it in there as standard text would be a step forward.

Ideally the information about which patches have been committed could be relayed from the parsing of the commit messages themselves, as long as the issue ID is present in the commit message. I've checked with the Version Control API folks, and they confirmed that there is a hook for new commits, that could be implemented in project_issue, to display the information at the top of the issue after parsing the issue number out of a commit message.

@mikey_p, #48: Let's spin-off #825404: Display commits against the issue then.

#825404 is duplicate with #443000: When viewing an issue, display a list of commits that reference that issue # -- but yes, I think that's the better solution than trying to cram that into the issue summary.

Just for the record, I do now totally support the summary field. I already missed it a lot in some issues.
The nodereference can be nice too, but the summary field alone would already be a huge step forward.

What do you think of Comment driven as a possible solution?
(to replace the soon abandoned Comment CCK)

adding redesign tag

subscribing...

... as suggested by Derek (dww), I am posting here the screenshot of how bugzilla.mozilla.org handles issues relationships:

http://drupal.org/files/issues/issue_relationship-depndency_0.png

I have not given up on this. Now that D7 is coming to fruition, we can rest for exactly 2 weeks and then start back on all the things we've deferred.

Here is my rant on improving the issue queue which I'll keep ranting about.

Hooray! It would be so great to improve our process early in the new dev cycle.

Here is a concrete proposal that dmitri, rfay, webchick, and I came up with at the Vancouver docs sprint today:

a) We will have a standard that the node body on an Issue node will be the issue summary.
b) Each project will be able to define a template for issue reports, and this will be inserted into the node body when you first create an issue, but of course the person adding the issue will be able to edit it.
c) Comment Driven (http://drupal.org/project/comment_driven) will be used to allow people to edit the issue summary (i.e. node body) as a comment. This field will be in a collapsed fieldset, so as not to clutter up the comment adding area of an issue.

We will discuss elsewhere (1) what the template should be for Drupal Core, and (2) If we need any process changes like requiring good summaries before committing and (3) what the default template should be for all Projects who have not defined their own.

This will solve the following:
a) 300 comments on an issue means it's hard to review an issue (for committers, documentation writers, etc.). This will give us a single place to look to understand what's happening on an issue.
b) Allow each project maintainer to define what is important for people to put into an issue report.

One complicating factor: Migration path.
Proposal: Take the current node body and duplicate it as a comment. This will be given #0 in the comment list, and a create date equal to the original node creation date/time. We won't mess with the existing node bodies.

From a technical perspective I really like it. My only concern is that without revision tracking, the actual bug report can easily be lost -- we see enough problems with people spuriously changing the title of an issue because they have a related problem, or want to editorialize. If we can somehow preserve the first post, or train people to capture details in the first comment of the issue, I think it could work well.

I do think this is a good way to approach it, though. Definitely simple.

Who said we won't have revision tracking? We have revision tracking on drupal.org in general, and anyone logged in can see the revisions (because we don't want Google et al to index them).

Also, the idea here is that the body would be changed in a comment, and I think the comment would have the new node body. Maybe we also need to have the original body be the first comment...

How about only maintainers having the permission to -manually- edit/update summaries based on people's comments + reference/link respective comment(s) along with each edit? This would transform the summary into some kind of 'captain's log' marking the progress/course of the issue over time and stating its current status.

IMHO we should avoid mixing/confusing the issues' original reports with their summaries, since the goals here are:

- To filter out unnecessary info such as 'subscribing' comments. This will be partially solved (at least improved) once we have a way of allowing people to subscribe to an issue without posting a comment (#288726: Allow users to subscribe without posting a comment).
- To point to the latest solution/patch available on top of the issue page, so that -for example- people that simply need to review/test don't have to go through the whole 300+ comments.
- To gather all useful info in one place (that's why its called a 'summary' - right?)

A nice addition would be to allow issues to reference each other in a depends-on/blocks manner (please see attached screenshot in #54 and #44162: Relationships between issues: support for parent issue and related issues)

PS: also related #33475: Attachment summary: Issue attachments should be grouped together and placed on top of the page - near the issue summary

I respectfully disagree with #60.

We definitely don't want to restrict editing the summary to just maintainers. In Drupal Core, at least, this would put a huge burden on the maintainers to edit these summaries, whereas one of the big benefits of the summaries was so that the maintainers/committers could easily figure out what has happened and what is proposed to be committed, what it will change, etc. by just reading the summary instead of reading the entire mess of comments.

We also don't want the summary to be a log of the comments and all the discussion on the issue. We want it to be a summary of what (finally) was decided: what the real problem is, and what the proposed patch or other fix does to resolve it. If someone wants a log of the comments and discussion, they can read the comments.

Maybe we also need to have the original body be the first comment...

I think we absolutely need something like this.
We should also keep the original title and other original settings in that first comment - the lack of which is already a problem today, if the title has changed, or the issue has been moved into a different module's queue.
These things can be collapsed if necessary.
It does not even have to be a comment technically, just something that gets displayed on top of the other comments, so this thing in combination with the comment text and comment_driven changesets make kind of an issue timeline.

The problem of losing the original post's meta data is here: #151984: display the initial issue metadata with the initial issue post. It seems a bit weird to have the original post duplicated with the first comment to try to solve that problem. We really need some bigger UI changes here if we're going to turn the issue node's body into an editable issue summary. I'd like to see some mockups of what an issue page would look like with this proposed change. I agree we need something like an issue summary, but I'm concerned we're going to make issues even more confusing unless you're already a seasoned issue queue veteran. I'd rather not make the default case for 98% of projects on d.o more complex and confusing just to (significantly, don't get me wrong) improve things for 2% of projects (including core) where this is a real problem.

What about some kind of "tabs" (js) to switch between "reply" (default, no editable fields except the comment body), "upload patch" (allows to set the status to "needs review" + file upload), and "edit issue", which reveals all issue editing fields.

The comment body would be shared between the tabs.

One system that does have a comment-driven like interface is trac.
http://trac.edgewall.org/
Here the "change ticket" is a collapsible fieldset, collapsed by default, but it is below the comment body field, not above it. I think this makes a lot more sense than what we have on d.o. And the "change ticket" is bold, in contrast to the "Edit issue settings" in d.o.
http://trac.edgewall.org/ticket/9907#no3

It looks like the issue description area in Trac is giving you a diff so you can see its history. Could we have that? It would just be node revisions I would think. Then we wouldn't have to worry about duplicating the original description in the first comment, or indeed in putting the new description in with the comment. The comment could just have something like:

Title: Old Title Here >> Brand New Title [this is what PI does now]
Description: updated (see history)
Category: bug report >> task

I finally got around to seeing the video of mikey_p's module. Palantir has been using Redmine for a while now and are reasonably happy with it, especially the improved issue functionality. At least as an incremental step I'd love to see that module integrated into d.o, as it would give us a lot more metadata to work with when corralling issues. The other discussion here can continue but that is at least a clear immediate benefit.

Title mashup, it's good to have the actual problem in there, not just the solution.

Bojhan, DamZ and I just talked a bit about this and DamZ has an alternate proposal:

He suggests a checkbox on a comment which marks it as an issue summary, and then the summary at the top of the node would have links to issue summaries which have been posted. It also does not require adding comment_driven, which he is opposed to.

I would be fine with this. It allows access to good issue summaries from the top of the issue, and allows multiple issue summaries (which might be associated with different cycles within the issue).

Sounds good. Multiple summaries would give us shortcuts to how the discussion evolved which seems valuable. Probably lowers barrier to summary-writing too, since you won't get the feeling you're editing The One True Summary.

I wrote a simple module to power this: https://github.com/damz/comment_highlight

We can easily migrate this information as a simple field attached to comments when we will have migrated to D7.

I like this.
Now everyone can tag their comment a "summary", but i assume in most cases people will be honest.

#69 seems quite reasonable to me too as a concept. Couldn't it be done in D6 (or for that matter D7) just as easily with Flag?

subscribe

@DamZ can you post an image, additionally for accessibility we need to make sure we add a "Summary" label thats visible beside the background color.

The proposal in #69 seems good to me. How often I've wanted to be able to draw peoples attention to a comment that I have written specifically as a summary of the progress in an issue to date.

I agree with Bojhan, there does need to be a textual representation of whatever style is assigned to a summary comment. This could go after the comment number, or after the "New" text for new comments. The first is preferred as it will be more easily noticeable by screen-reader users who otherwise need to listen to the entire line of text to find the "Summary" identifier.

The specific proposal we're discussing has changed (again), so re-titling to capture the point of the original point of this thread (as with comment #10). ;)

In fact, this whole new direction of flagging specific comments as summary comments is basically a separate problem. All issues could stand to have reasonable summaries. This issue was specifically to capture the problem of meta issues to coordinate larger "projects" (in the GTD, not drupal.org sense) that involve multiple tasks/issues.

So let's discuss flagging comments as summaries in a new issue. To that end:

#1036132: Provide a mechanism for issue summaries

Also, since this never happened during the initial redesign launch, I'm untagging it.

I posted this on g.d.o http://groups.drupal.org/node/118474 but realized I should add the info here too, though it might not be relevant enough in regards to summaries (or may need its own issue) - just some of the features i've found useful as a PM using unfuddle to organize related/meta issues - usually i create a parent issue/ticket and then relate it to child/related issues

--------

i thought that it might be of use for me to post some screenshots of how some of the features you noted on slide 5 [of randy's slideshare from http://groups.drupal.org/node/118474] are handled in unfuddle (project management software):

- related issues:

- associated commits:

Even more meta issue for issue queue redesign: #1079506: Redesign the issue queue

And Core conversation at Drupalcon Chicago about the issue queue - hope you can all come.

Redesigning the Issue Queue.

Time slot: Thursday March 10th, 1:00 PM - 2:00 PM
Room: Michigan A/B

subscribe

+1000 to issue relationships and commits associated with an issue display

We all want it but keep running into stuff:

http://drupal.org/project/issues/search/?issue_tags=prairie (not all but many of these revolve around issue queue changes)

Said in the least contentious voice possible:

Why can't we implement a few of the small, easy to address, and most needed changes (eg. issue relationships and a sprint/phase field - tying commits may be harder, I'm not sure?) fairly immediately, so that we have the tools we need in the interim? The Prairie Initiative has turned into a massive project that will take a lot of time and effort, and it would seem it's delaying some of these low-hanging fruit that would be so helpful.

Yep. Do not let Prairie hold up any tweaks we agree would be great to have.

@arianek #84: We're making tons of progress on issue summaries at #1036132: Provide a mechanism for issue summaries and that's *very* close to being deployed. That's going to significantly aid this, since anyone will be able the edit the issue node body itself. So, meta issues will be a lot easier to handle once that's live.

The Project Issue Related module has some serious performance issues and mikey_p was basically re-writing it to be deployable. I think he's made a lot of progress on that, too, but I haven't had a chance to catch up with him about it, nor read the commit logs myself. I'm sure interested parties would be welcome to meet him over at the issue queue and/or in IRC.

Finally, to the extent I speak for anyone, I think I can safely say that all of us active on the prairie want to get low hanging fruit done and deployed ASAP... However, at this point it's still all volunteer work, and that means it has to be juggled with the dozens of other things vying for our volunteer attention. This is all really important stuff, and for now I'm putting as many free hours a week as I can spare on it, but it's hard with everything else going on in my life these days...

Cheers,
-Derek

...lets see if I can manage to find some time to go through the issue and get a dissent summary together.

Related/duplicate: #1300972: Implement initiative content type

Maybe we should just close this and focus on that? Certainly need to keep our eyes on that.

Would be love to see movement on this now that we've upgraded to D7.

So is the next step in this upgrading one of these modules to D7 and providing a patch to Bluecheese?

https://drupal.org/project/pi_related
https://github.com/damz/comment_highlight

EDIT: Also interesting discussion related to "meta" discussions/brainstorming here https://groups.drupal.org/node/133169#comment-437344

Is this still needed, now that we have "plan" issues?

I think it may not be needed.