[META] Issue page redesign

Just updated the summary with lots more info and context about the changes and what we're talking about here. Also, tagging appropriately.

Added a link to #1545952: [META] UI for updating an issue in D7 for the UI for actually updating the issue.

Following this issue, I will post some ideas I have laying around as soon as I get the chance to clean them up.

I have removed and re sized some of the images, for an easier visual discussion. I don't think we need full size screenshot to understand the purpose of each tab, so did not display them.

Displaying the 'all commits' wireframe.

Excited to see this happening! We had some discussions/work done on issue page redesign at Prairie initiative.

The main wiki is here: http://groups.drupal.org/node/144574

Leisa collected user journeys via UserVoice voting.

And created Initial wireframe.

After getting some feedback she created wireframe V2

As I've been harping on this one at every opportunity I get, I couldn't pass it up now. ;)

I'd like to suggest that the 'Version' field in box 1 be changed to 'Branch' ... this will help reinforce the concept that project_issue should support more than 'release' versions (which in turn enables additional related functionality for i) sandbox issue queues and ii) issues specific to a particular feature branch under development).

In Box #2, I'd order the files from newest to oldest (ie. descending comment id).

I've also been trying to come up with a UX which would allow folks to mark certain patches as 'obsolete'. As an example, when a patch is uploaded with a typo and that typo is fixed with a new patch in the next comment, that bad patch hangs around in the patch list and contributes 'noise' to the issue for perpetuity.

It would be nice to have some way of screening out those patches and the 'noise' they contributes, so that the 'patch list' can be kept both concise and relevant. However, the implementation should not create the ability to screen out someone else's patch simply because you stand on the opposite side of the bikeshed argument. ;)

So far, the best I've been able to come up with is a 'hide' link associated with a given patch/file, which is only visible/available to the owner of that actual patch, which allows them to flag when their particular patch has been superceded or is no longer relevant to the issue.

As someone that forgets --relative when making patches and ends up having a patch referencing custom, unrelated, yea, it'd be be nice to delete/remove/hide files.

you _u_ instead of _you_ in the screenshot makes me twitch :(. Could have a really_really_really_really_really_really_really_really_really_really_really_really_long_filename.patch as an example.

If I understand the OP correctly, then it wants to "equalize" the two operations of 1) updating the issue and 2) adding to an issue, because they are difficult to understand currently.

If that is the case, then I do not believe that this is the proper direction to take. The problem and cause is that we don't make it clear that there are two things involved in an issue: 1) The issue/status-quo itself, and 2) A stream of discussion, input, files, reviews, etc. Mixing these two even more will make the situation worse, IMHO.

A list of all files in an issue at the top is pointless, because each file needs additional information to provide the necessary context. In an issue with 300+ comments, there will be a giant list of patch files, screenshots, and other files - you always need to read the corresponding comment for a particular file to make sense of it. That even applies to screenshots or design mockup attachments.

Filtering the stream of comments, property changes, and commits by these three types might be helpful, but that can be achieved in a few lines of JavaScript, and I'm really not sure how helpful that's going to be in the end. To properly understand an issue and its discussion, you usually need to read everything that has been added to it -- unless the issue summary has been properly updated and fully represents and covers all details of the discussion, approaches, pitfalls, etc up until now.

And that's pretty much what it boils down to for me: Instead of making the stream even more ambiguous with the issue/summary/properties, we should properly communicate these two parts of the concept. People need to understand that they can discuss, bikeshed, design, patch, prototype, and do whatever is necessary to resolve an issue - but whenever any kind of milestone is reached, they ought to update the issue (summary) accordingly to clarify what the current state of affairs is, which solution proposals have been investigated, which questions are still open, what related or unrelated issues are known and will be resolved later, etc.pp. (i.e., give a complete picture) so that others don't have to read the entire stream.

The concept of topic and stream isn't really new or something special. Check http://en.wikipedia.org/wiki/Drupal :

1) Topic/issue/summary/status-quo
2) Revisions/history
3) Discussion(s)

If someone is going to change the issue, then he better explain why. If people can simply change issue properties without any explanation, then we'll see a lot of issue changes (more than today) without reasoning. If we want to encourage an explanation, then we end up with the system we have today. (which is good)

In the end, I would rather want to see a world in which particular comments and also file attachments within the stream can be flagged in various ways, so they are automatically pulled/aggregated into the issue summary. Flags to denote important comments, comments containing open questions, the current patch for major version X, same for version Y, the test-only patch, and so on. On top of that, it should be possible to split the stream into multiple sub-streams, so people can start to discuss individual questions as sub-topics and come to separate conclusions. Those sub-stream topics and their conclusions would be pulled into the summary, too.

But none of these would ever replace the importance of having a clearly separated issue summary and main issue properties.

(Lastly, you might want to have a look at Differ module)

@sun: Thanks for the feedback. Sadly, you're missing various points (probably due to the original post not providing enough context, or you not reading it closely enough). You're also probably stuck in the "this is the way it's worked for 10 years, so any change is a problem" way of thinking. ;)

- Updating an issue will always require you to specify a reason. That reason will be used as the body of the comment we generate for you. So, if you want to just read the whole firehose of comments, you'll get all your context right there. No one will be able to change issues without being asked to explain why. Of course, that doesn't ensure useful data, but at least it will require data. ;)

- Currently, because updating the summary is a totally separate operation, people don't tend to do it. One of the goals here is to make it more likely/easy for someone to just update the issue summary if they're trying to update the issue. We want the summary to always reflect the current status. Sometimes you'll still need to read all 300 comments. But, you shouldn't *always* have to read all 300 comments. Ideally, everything you actually need to know about an issue is on the first page or two of the issue, not scrolling down and back over and over to make sense of the current status.

- All the files for an issue are going to be attached to the issue, not individual comments. If you want to add more files, you update the issue and add them. There's lots of talk about functionality to mark other files obsolete when you reroll a patch, etc. That should probably be split to a separate issue so as not to get too lost in those details while talking about the big picture here. However, the intention is that the table at the top is not *all* files, but the most recent or whatever. There's supposed to be a link to "see all" to expand the full table. Maybe the obsolete files will be wrapped in <del> or whatever.

- We don't want differ. That whole way of doing things is kind of insane. Yes, that's how project_issue has worked for 10 years, but that doesn't make it a good idea. ;) Instead of jumping through a *lot* of hoops to alter the comment form to turn it into a quasi node edit form -- if you want to update the issue, just edit the issue. If you want to discuss and just comment, add a comment. It's far easier to auto-generate a comment for each node revision that includes the changes than it is to actually make the comment form the way to change the node.

@jthorston: Re: "branch" -- that's not always true. Sometimes an issue is relative to a specific version, not a generic branch. Let's please not re-hash that debate here. Let's continue to discuss that at #1328928: Refactor version selection box to leverage "version strings" instead of "release strings" instead.

This looks pretty solid. The architecture feels a bit odd since I'm comfortable with the existing one, but I can't think of ways it's necessarily wrong. I wonder about scalability of creating so many revisions.

mysql> select count(1) from comments c inner join node n on c.nid = n.nid where n.type = 'project_issue';
+----------+
| count(1) |
+----------+
|  2,717,541 | 
+----------+
1 row in set (7.01 sec)

mysql> select count(1) from node_revisions nr inner join node n on nr.nid = n.nid where n.type = 'project_issue';
+----------+
| count(1) |
+----------+
|   549,577 | 
+----------+
1 row in set (3.50 sec)

mysql> select count(1)  from node n where n.type = 'project_issue';+----------+
| count(1) |
+----------+
|   533353 | 
+----------+
1 row in set (3.96 sec)

We have almost 3 million comments on project_issues on d.o but basically have a 1:1 relationship between issue nodes and revisions. I'm not saying this is an issue, it's just a join that we probably haven't looked to optimize much.

I tried to think of Leisa's wireframe and the current proposed mockup (_v3) and if they can be combined much, if any. I'm not sure they can/should.

My initial reaction was that "Update this issue" is getting a bit more prominence than I'd like given the current workflow. However, once I read the full concept of flow I'm very happy with it.

wait - are you saying that almost all of my issue operations will become two step operations in the future? i.e., write comment here, afterwards change issue properties there? (and upload files somewhere in between?)

I hope not. I'm confused. The issue summary could indeed use some love - the resolution talks about problems, and the actual proposed resolution isn't clear.

(...and FWIW, no, I'm not stuck in habits; instead, having to work with the utter ugliness of various other issue/ticket trackers day in and out, and only wish they'd implement some of the concepts we have on d.o.)

wait - are you saying that almost all of my issue operations will become two step operations in the future? i.e., write comment here, afterwards change issue properties there? (and upload files somewhere in between?)

No, although I can see how you'd get that from the wireframes. We should probably wireframe the node edit form too.

Your operation becomes:

1. Decision: do I want to merely add a comment or do I want to edit issue properties (metadata, summary, attached files)?
2a. If you want to add a comment, add a comment.
2b. If you want to do anything else, edit the issue. There will be a required "Reason" field (exact title TBD) to associate with your changes. The content from this field gets appended to the issue as a comment (along with a diff of the stuff you changed)

Then the comment stream becomes a mix of discussion, files, issue metadata, etc. In other words, it looks exactly as it does now.

@sun: Right, what webchick said. *Anything* you do to change and issue would be updating/editing the issue. The UI for that will be hashed out at #1545952: [META] UI for updating an issue in D7.

@greggles: Re: scalability. Not every comment on an issue changes the issue. Many are just comments. Those can remain comments. Only "updates" (or whatever we call them) that actually change something about the issue would generate a new revision.

All that said, I'll try to update the summary to be more clear. I realize lots of the context and reasoning is still in my head...

Fleshed out the problem/motivation section more (to hopefully make it clearer what we're talking about) and also re-emphasized some key points in the proposed resolution section.

Just did a few major edits to the summary:
- better explained the problems we're trying to solve in the first section
- added a whole separate section about the table of file attachments

I hope that's a lot more clear. Please let me know if there's anything else I can do here to make this more easily understood.

Thanks,
-Derek

@dww (#14): I realize that some (rather, the majority) of issues are relative to a 'version'. However, as I understand this to be a 'pre-coding' mockup, intended to help define the redesigned architecture, the intent of my suggestion is to draw attention to the 'not-so-edge' cases (i.e. sandboxes and feature/initiative branches), and ensure they are considered in the design from the start.

Maybe full projects default to 'version', and sandbox projects default to 'branch' ... I don't know. But by positioning it solely as 'version' (which I interpret as 'release'), this excludes all sandbox projects; which definately need to be considered within the scope of this mockup evaluation.

As far as 'rehashing the debate' goes, there wouldn't be a need to bring this up here if the original issue had already been debated to any sort of conclusion - but since it wasn't, and this item has repeatedly blocked me on my own initiatives, I'm going to do whatever it takes to ensure that this particular design limitation isn't carried forward into the redesign as well.

To provide background for others, the context here is a proposal to use the versioncontrol_label id (i.e. 'branch' id) to datafill the version drop-down tab, instead of today's versioncontrol_release_label id (or 'release' nid). The motivation is that sandbox projects do not have releases, which means no entry in the versioncontrol_release_label table ... and by extension, no ability to set an issue 'version' (which is what the testbots key off of to determine which codebase to check out for any given patch). Whether this 'versions' list is then filtered down to releases only could be handled a per-project or per-issue basis.

Re #21: "version" is just a version. The fact you're interpreting that to mean "release node ID" b/c that's how it's worked in the past is your deal, not mine. ;) We're not saying "release id" in these mockups or in the summary here. Anyway, this is really off topic. The fact that I haven't had a chance to have the discussion yet doesn't mean I'm ignoring it or forgetting it. I just have lots of things to deal with and can't be everywhere at once. The fact I'm linking to your issue means it's on my radar. ;) However, to make you feel better, I'll try to respond there. But please, this issue here is going to be contentious and bikesheddy enough as it is. Let's not also confuse matters even more with this (entirely unrelated) discussion about making the testbot happy on sandbox projects.

Thanks,
-Derek

To provide background for others, the context here is a proposal to use the versioncontrol_label id (i.e. 'branch' id) to datafill the version drop-down tab, instead of today's versioncontrol_release_label id (or 'release' nid). The motivation is that sandbox projects do not have releases, which means no entry in the versioncontrol_release_label table ... and by extension, no ability to set an issue 'version' (which is what the testbots key off of to determine which codebase to check out for any given patch). Whether this 'versions' list is then filtered down to releases only could be handled a per-project or per-issue basis.

We can not use versioncontrol label id's because we can not make sure they will be there in the future, versiocontrol needs the ability to add/remove them. In the d.o specific case, the git hooks make sure the push does not remove a branch which is used on a release(i.e. -dev releases), but topic branches can add and remove them as the maintainers want.

But yes, considering the way sandbox projects interact could be a good case to consider here.

You're right, I misinterpreted the context of your response in #14, which led to the redirect feeling more like a dismissal. ;)

Okay, I replied at #1328928-2: Refactor version selection box to leverage "version strings" instead of "release strings". ;) Please, let's stop talking about how we represent version strings here!. I'm going to start unpublishing comments about that as totally off-topic and distraction from the real point of this issue, which is getting clarity and agreement on this thing about all changes to the issue happen as direct node revisions, not pseudo-node-form comment insanity. ;)

Thanks,
-Derek

it will also massively simplify the code in project_issue since we'll no longer be trying the horrible task of altering the comment form to turn it into a quasi-node-edit form.

While the technical merits may be secondary, I don't think that this is going to be the case, as you're merely switching around the integration of two-forms-in-one.

UI-wise, I can't stress enough that the corresponding comment for a particular patch is extremely important. There's no point in reviewing a patch, if the corresponding comment says:

Here we go, an initial prototype - I've only converted the Flubby subsystem, and the patch contains plenty of todos and debugging code. Let's discuss! (also, obviously, this will fail, so leaving at needs work)

The same goes for screenshots and design work -- you always need context to prepare your mindset for the considerations and level of maturity you're going to see.

Furthermore, from a technical perspective, I'm not sure whether it is wise to attach files to the issue instead of comments. I realize that we still have a uid in file_managed, and that you could potentially use a second file ID reference in the corresponding comment, but this architectural proposal makes me feel uneasy, but I can't explain why currently.

UI-wise, I can't stress enough that the corresponding comment for a particular patch is extremely important. There's no point in reviewing a patch, if the corresponding comment says:

At least in person on Monday we definitely discussed having a link next to each file that would link directly to the individual comment that added the specific file. This would make finding the comments about each file very easy.

Also, I don't think this proposal entails *removing* the display of files from comments. My impression is that an update that adds a file would look almost identical to the current system of adding a patch to a comment, so there would be no loss in functionality if you want to read through the comments. This is more of an additional feature being added, but not at the expense of useful context that we currently support.

"... update that adds a file would look almost identical to the current system of adding a patch to a comment ..."

+1 ... I'd envision an uploaded file having an additional field used to associate it with a particular comment within the issue thread (as just one example implementation), but still have the file attached to the issue node itself. Architecturally, it may feel like a convoluted way to sustain the existing workflow, but in the background it eliminates the need for SQL joins between upload and comment_upload for any patch-related queries, thus simplifying the implementation of projects such as PIFT.

Most everything I read in the summary sounds very useful to me. However:

Updating an issue will always require you to specify a reason. That reason will be used as the body of the comment we generate for you.

This sounds like a real pain in the ass to me. It's NR because some novice doesn't know that they should set it. Do I have to type something? I added some freaking punctuation to the summary. Do I have to type something? Someone not familiar with our practices set the version to 7.12 because they are using 7.12. Do I have to type something? Tedious.

I do love anything that facilitates updating the summary more easily, and I do find I have to educate people constantly about posting comments to change issue properties. Overall I can see it as a great idea; I just can also see myself getting very growly (or entering lots of useless .) if I have to justify self-evident changes.

I do think listing patches in one place is a UX improvement. However, I'd want to allow grouping them. Our current workflow involves grouping test-only patches, interdiffs, D7 versions etc. with a single primary patch, adn I don't want to lose or befuddle that.

I'm commenting on the text of the issue only as the mockups are just conceptualizing. I'd also like to see discussion of the prompts to the user for the summary. I would really like to make writing summaries easier for people and I'd really like better prompts on what to put in them.

added section about the files table and how files would be handled

@xjm: Excellent point. I was trying to address the concerns about context and realized I swung too far in the other direction. The comment body on issue followups used to be required, and resulted in a lot of bogus "." comments when people just needed to change the status or something. Any issue update will still generate a comment, but if you don't provide a revision log message, the comment will just contain the meta data diff. We'll still want to alter the form a bit so the log message isn't so buried in the UI, but we don't have to make it a required field. I just updated the summary to reflect this.

Thanks for your feedback!

Cheers,
-Derek

More thoughts; I think if we put the "Reason" or whatever field FIRST on the update-issue form, that would help it not get ignored when it's relevant; but still allow omitting it if desirable.

Regarding comments on patches, I almost find the jump-to link for the comment for the patch to be too out of context. Edit: Sorry, what I mean here is that it's not easy to scan for the information I want, which is what exactly this latest patch is and what my reaction to it should be. I guess I sort of agree with sun in that regard, but I'm not sure how to fix it without further cluttering the info at the top.

With the comment vs. update, I often start writing a comment, then realise I need to do an update. I've been using Jira at a work project recently, and it has the same thing, which generally means copying/pasting the text you were writing, clicking through a JavaScript warning that you're about to lose the text you just copied/pasted, clicking edit, scrolling to the bottom of a very long form to paste the comment back in, then making the issue changes. If we can avoid a UI like that, it'd be good ;) xjm's idea about putting the comment form at the top of the edit form might help with this.

In general I think making the issues more 'summary focused' makes sense, it's going to be a lot of getting used to for those of us used to scanning down comments.

Are we planning to have "This issue blocks: ..." and "This issue is blocked by: ..." sections?

Q: With the entire form at the top, how do we facilitate regular discussions? (which mostly are comments, but often also need to change issue properties/tags, but alas, naturally added at the bottom of the page, after the last comment of the discussion)

Do we duplicate the entire form at the bottom...?

Among others there were 2 ideas for issue page redesign in Prairie group:
1. related issues
semi-automatic/manually edited list of related issues, to provide more context for an issue

2. 2-level threaded comments
to separate big ideas/suggestions from general chit-chat comments
(means that you can comment on first type of comments, instead of always commenting directly on an issue)

I wonder if you considered these 2?

Re: Related issues (#33, #35) -- definitely considered. Not yet visibile in the mockups or reflected in the summary. That's what #44162: Relationships between issues: support for parent issue and related issues is about. I know so much of this stuff is just in my head, leading to all sorts of concerns being justifiably raised since no one else has all the context I do. ;)

Re: 2-level threading (#35) -- yeah, we've talked some about threading, and generally decided it was a bad idea. ;) But, I can see some value in the kind of restricted threading you're talking about. However, it gets really complicated, especially once you consider auto-generated comments whenever someone updates the issue. How are those supposed to be threaded? I think overall, threaded comments are going to create more problems than they solve, but I'm definitely interested in discussing that in more depth, although that should almost certainly be its own separate issue.

Re: #34 and where/how the update form works -- that's really what #1545952: [META] UI for updating an issue in D7 is all about. Although they're obviously closely related, I'm envisioning *this* issue more as how people will read and understand an issue, and that issue is about the details on what updating an issue will look like. Maybe that's an arbitrary distinction that only makes sense to me and that thread should be folded in here.

That said, maybe the scope of this issue is too broad, and everyone's therefore (understandably) approaching it as another meta "redesign the issue queue" discussion. Perhaps it should be more narrowly focused on the thing I actually wanted to get community buy-in on, namely that you can no longer update an issue by commenting, but instead, you update the issue directly (and some basic understanding of what the issue page might look like as a result of that change).

I would consider just using a scrollable div for the table of files; you don't have to do anything special for that, it makes it compact. You probably only want to see the top 5 or 6 files anyway, and you can just scroll down in that table to see more with minimal hassle. Reverse chron order for sure.

I really really like having commits tied. Please be sure that the branch committed to is easily seen. A would-be-nice addition would to also note which tags the commits are in. That way you can tell the difference between "Committed but not release" and "Committed and released in 7.14".

I am concerned that an extra click to add a comment might be kind of annoying. I'm pretty used to the comment form always being at the bottom. But I can see where that may be necessary to keep things from getting TOO busy.

Alright, first review of this issue so bare with me. I am only giving feedback on the functionality, not yet doing any design.

Fundamentally I agree with the notion that we should try and separate commenting from changing the status of an issue, although in core its far less likely to change status without a comment it seems to be far more common in the contrib world. I imagine to solve the issue of having to go to two places to change the status, we could allow some quick adding of a comment at the top or quick status change at the bottom. As sun clearly points out this needs more wireframing, as the flow to do this is currently not clear.

I am a little bit troubled by the introduction of so many new parts in the wireframe, I think we should first align our priorities. The user stories try to do this, but we need a "top 5" we can focus the design on, because right now it seems we are jumping to wireframing making the most important parts less important, just to fit those new ideas (e.g. the summary is now the least prominent part of the page). It seems a lot of discussion is around the specifics, of what each area its interaction could be - rather than a conceptual discussion on whether we should have them or not.

From just my point of view, I think the goal is to connect the "top" part of our page better with the actual discussion; directing more activity to the header, and/or providing auto-updating mechanisms like with files. We definitely do not want to break the current flow, requiring users to move between the top and the bottom.

I love that we can finally redesign this, I have had ideas about this the first few days I started using the issue queue but never got around to making them happen. Should we just get a list of prioritized functionality going?

No, we don't want a separate "Solution" field.

There are only two pragmatic directions with regard to that - either fully turn the issue summary into dedicated, separate fields (which requires to agree on a proper summary template first) and ditch the body - or retain the full summary as one long text that can contain a summary that may follow a common template (or not).

Mostly agreed on #41, I think.

@Senpai, what sun I believe is saying--what I'm saying--is that, while the general idea of having separate fields for the problem and the solution could be useful, so would explicit fields for other parts of the data that should go in the summary. (Edit: and adding fields for these two but not the others could distract from the data for others getting posted). Additional fields might include optional fields to indicate details on the issue's current status and next steps; followup and related issues; specific details about the patch like UI/API changes, etc.

In our current summary template there is

1. "Problem/motivation" (the word "motivation is not a good prompt in that it invites some rather literary exposition at times).
2. "Proposed resolution"
3. "Remaining tasks" (also not a good prompt as too often this gets filled with redundant and misleading stuff like "patch needs to be marked RTBC then committed" rather than useful information)
4. "API Changes" (more often than not "none")
5. "UI Changes" (more often than not "none")

sun disagrees with our current issue summary template (and I'd agree that it has weakenesses in practice, at least), so in his opinion codifying the existing template rather than trying to improve it would be premature. (However, I personally don't find sun's proposed template that much better. :P)

My two cents is that blindly adding a lot of additional fields would complicate the form for novices, but if they were hidden or conditionally displayed we could still create good UX and add useful metadata. This is part of what I was getting at in #29. For example, imagine:

• If you enter issue #12346 as a followup for #12345, then #12345 is automatically listed somewhere on #12346.
• Integrating the UI and API change fields directly into our change notice workflow rather than creating new nodes, etc.
• A nice clear field that prompts users to indicate steps to reproduce a bug starting from installing that project (#1465924: Add explicit field/section for steps to reproduce).

However, I'm not sure whether these questions are out of scope.

Yeah, we had a similar discussion at a whiteboard. -100 to 100 new fields. :)

The idea behind separating problem/solution though is that the issue page is serving at least 4-5 different target audiences that we were able to identify. And the biggest one (in terms of raw numbers) is "I'm a user who is receiving this error on my site / wants this functionality and I need a fix."

These people don't care about the history of the issue, the discussion, who is involved, what the proposed resolution is, what the remaining tasks or are, what API changes there are, etc. Basically, any of the information "above the fold." What they want to know is "Apply patch #4" or "Download 7.13" or whatever. And the absence of this information being easy to find right now leads to (often irritating) comments that totally disrupt and derail the work that contributors trying to fix the problem are working on, or that spam all 100 participants once an issue is fixed.

However, contributors care about this information, too. It helps them focus on which patches to review, what work is missing, etc.

So while I don't think there's value in separating all of the fields in the issue summary template (and agree the issue summary template probably could use some work now that we've used them for a few months), there definitely seems to be value in separating this particular one out.

What webchick said. ;)

Furthermore, related issues have no business in the summary as text. That's going to be handled via a multi-valued "related issues" entity_reference field over at #44162: Relationships between issues: support for parent issue and related issues, and perhaps a single-valued "parent issue" entity_reference so you can track subtasks, etc. All of that magic belongs as explicit (if optional and by-default-buried) fields so we can do automated functionality with it, not manually managed via text areas.

That's going to be handled via a multi-valued "related issues" entity_reference field over at #44162: Relationships between issues (integrated with the status field), and perhaps a single-valued "parent issue" entity_reference so you can track subtasks, etc.

while (1) {
  +1;
}

Hooray for related and parent issues fields!

I think webchick just changed my stance on the solution field ... I can see tremendous value in a solution field, which might contain text such as "Apply patch X from Comment Y" or "Use Release Z", and generally wouldn't be datafilled until an issue is marked 'fixed'.

If this is the intent, then perhaps a 'final resolution' or 'final outcome' label would help to avoid the conflict between this field and the solution text within the Issue summary template; which I have always interpreted as being intended for the "proposed solution" information.

> All the files for an issue are going to be attached to the issue, not individual comments.

The problem I see with this is that when I look at the most recent wireframe attached to this issue, I don't understand how I'm meant to know what the different files are. All I have to go on is there filename. How do I join that up with an explanation of who made it and what they have to say about it?

The "number" column is a jump-link to the comment that was auto-generated when that file was attached to the issue. Presumably, the author described the file in their "Reason for the change" field (aka the revision log message) which will be very prominent on the update UI (perhaps at the very top of the form).

omgomgomg at #44162: Relationships between issues: support for parent issue and related issues. Yay!

The "number" column is a jump-link to the comment that was auto-generated when that file was attached to the issue. Presumably, the author described the file in their "Reason for the change" field (aka the revision log message) which will be very prominent on the update UI (perhaps at the very top of the form).

I am wondering if there's some way we could supply more context? a one-liner that has the first few words of the comment, or a magic javascripty jquery expandy thingy? a jump link seems like a disorienting way to do this. =/

So, with the two fields, I guess the solution field would include the information we currently put in remaining tasks, UI changes, API changes?

And STR go in the problem field? =/ I'd still dearly love it if an STR field magically appeared when the issue was filed as a bug report. But a minimum, this:

Problem

Include steps to reproduce your issue.

_______________________________________________________
|                                                     |
|                                                     |
|                                                     |
_______________________________________________________

No fine print surrounded by other fine print halfway across the page.

> the comment that was auto-generated when that file was attached to the issue.
> the author described the file in their "Reason for the change" field (aka the revision log message)

So there are two streams of comment-type things -- actual comments and revision log. I describe what my patch does in the log, and then other people write their reviews in the comments?

Hmm. It would be lovely to be able to attach a review to a specific patch. Too confusing?

My point was more that currently we have just the one stream of comments and here it looks like we will have two.

If we're going to have more than one stream, then having a comments on the patches could make sense. Because otherwise, the conversation about a particular patch is split between the initial comment which is in the log, and the comments on it, which are actual comments.

Though I am worried that multiple streams will make it hard to follow what is going on.

@Joachim - We'll have multiple methods of entering them but just one stream of reading them.

1. I could see the point of adding a separate widget that basically embeds change notices into an issue.

   That would have various benefits, of which first and foremost probably is that change notices would get written as part of the issue summary already (and would evolve and be adjusted as the issue progresses). It would also clarify what exactly a particular issue wants to change.

   Change notices are pretty generic, so they'd even work for issues like this here. You'd typically do a before/after comparison with screenshots to explain the change.

   Drawback #1 would be the argument that the current terminology uses "API/UI changes" and that's not really generic enough to apply to all kind of issues. However, I could personally see us resolving that by coming up with a generic terminology along the lines of "Expected change" (which is bad either and will lead to wrong input). It won't be easy, but I think the exact terminology can be figured out.

   Drawback #2 would be that not all types of issues lead to a change. For example, just consider support requests. There are a lot of issues that don't really have any kind of "solution", nor any kind of "change" in the end (or at any point in time in between). The separate field will be confuse users.

2. I do not see the point of merely separating problem and solution as discussed here. Even more so - if I interpreted above discussion correctly - if that solution field wouldn't be the actual solution, but only a strange field that contains pointers for people in terms of which patch to use in order to hack core, or similar.

   Experience with the current issue summary template clearly shows that even more experienced developers do not get the point of a couple of summary sections and fill in random crap.

   Remaining tasks
   Discuss and find a solution for this, write a patch and tests, review it, and get it committed.

   Each time I've to read that I'm thinking "Oh seriously? Thanks for wasting my time, again."

   What's important to understand is that people feel that they're urged to fill something in, just because the section/field is there.

   A good template as well as interface design needs to have that in mind and prevent it. This is important, since each and every useless information in an issue delays the resolution of the issue.

3. @xjm's suggestion for attaching patch reviews to a file/comment seems to make sense at first sight, but reality is also that patch reviews too often go hand in hand with architectural remarks, questions, and discussions that are related to the overall issue, not to a specific patch being reviewed in particular. So on second sight, this would introduce a somewhat confusingly threaded stream of information that has a high potential of losing important information in sub-threads.

Also, and this is maybe thinking wayyyyyy too far ahead (and anybody do shoot this down if that's the case :), but there was talk at one point that as part of Git Migration Phase XXX we'd have one repository per issue, with something like a branch or a tag taking the place of a patch.

Maybe I need to put this in bold in the summary, but I'll say it here for now:

Even with the underlying shift to updating the issue directly instead of changing the issue by adding a comment, the experience for people reading an issue will be almost entirely unchanged. You'll still have a summary of the current status at the top of the page, and a firehose of comments about the issue that indicate every contribution to the discussion and/or change to the state of the issue. There are no separate comment streams to read. We might have the tabs to let you filter the stream to only see the times the issue was updated, only see the commits, etc, but the default view will be to see the whole history in chronological order, just like we have today. Each comment will have all the info it does now -- any issue state changes, any new files, etc.

---

Specifically in terms of problem vs. solution -- that's not central to this discussion, and I'm not stuck on rolling that out as part of this initial shift. I think Bojhan's comment turning this into a catch-all "Issue page redesign" issue is the wrong direction. Yes, it's good to have a big picture and a unified plan, but it seems very easy to get distracted talking about specific details and getting hung up on parts that aren't critical to the fundamental shift. Personally, I think it'd be better to debate each of those in its own issue, instead of a big confusing N-way debate in here. To that end, I'd encourage folks to participate in these related threads:

#1545952: [META] UI for updating an issue in D7
#1549280: Provide an explicit relationship between patches and comments about patches
#1553546: Encourage issue queue participants to clearly formulate the problem separately from proposed solutions

---

Re: embedding change notices into the issue itself -- no thanks. ;) We're already on the verge of making issues impossibly complicated with tons of separate fields and junk. Trying to wedge change notices into all that just seems like a recipe for complication, confusion, and disaster. If there are problems with the current ways we handle change notice nodes, let's address those in separate issues, too. But we shouldn't over-engineer and complicate all issues for the relatively tiny number of issues that result in change notices.

---

All that said, although there's been some healthy debate in here, my take is that there's overwhelming support for the general direction I'm proposing. It certainly makes the underlying code vastly simpler, removes a ton of ugly hacks, and will make issues far more flexible since you can add anything you want to an issue node type and you don't need to hack in support for various comment_driven-style solutions to allow participants to update those new fields.

Thanks to everyone who's been contributing here, I think it's been a very productive discussion so far.

@dww I love how you are trying to be, not ambitious. But the reason I asked for priorities, not because I want to make the scope bigger but because you need priorities to make a good design. I am not going to wait another 5 years, to get the chance to make this better as a whole. At some point, there is a limit to what we can do by designing small parts - at some point you need to address the patterns.

I had several requests to turn the wireframe into a more thorough visual concept, webchick told me the deadline for getting this moving is only a few weeks. I personally won't have the time to do loads of UX iterations on this, given the busy Drupal core UX-team obligations.

My proposal is below, I hope this is the correct issue to share them. What I have done is brought focus of the page onto the summary, and applied a more hierarchy to the elements presented in the side.

1. Issue status and priority
   This is often the most important information of an issue, but currently in a small non prominent box at the top of the page. In my redesign they have visually a very prominent role, they are a landmark for other information about the issue. I do realize that we need to figure out how this scales to longer issue statuses, we can do this by using a smaller font size and/or simplyfing some of the issue statuses (Wont fix, To be ported, Ready, Fixed etc).
2. Follow a more prominent place
   The follow button currently has little prominence on the page, this largely has to do with hierarchy as we place no important information on the right hand side. By pulling it near the issue metadata, I hope to make it more prominent element.
3. Files/commits/notices have a separate box
   I have added the pattern of collapsible boxes for information such as files, commits and possibly notices. Depending on what we want, these could be expanded or closed by default (toggled by cookie?). The primary downside of this pattern is that we are limited in the amount of information that can be placed in the box (e.g. with files, no username), but also might look somewhat awkward because vertically it could be longer than the information on the left. However I see this as a downside, to the upside that this is a scale able pattern, puts emphasis on the content of the issue and creates a more calm visual experience.
4. Full width comments
   A common move so far has been to reduce the "comment area" moving away from the full width it currently has. I think this is wrong, the discussion in the end is the most important part. Which benefits greatly from being able to leverage the full width.

Below is how this could look if the boxes are collapsed, a very simple listing in condensed form. The way that information is presented in these boxes is still very much up for grabs, I just put in the information from the wireframes.

I am not entirely happy with the location of the "edit" link but I am also kind of waiting on what comes out of #1545952: [META] UI for updating an issue in D7 to give this a more definitive place. Nor am I happy with the follow button spacing, but these are all issues that could be tweaked later on in the process. (Did anyone notice, all our comments are currently misaligned? )

Let me know what you think!

This seems pretty solid to me.

@bojhan - your design has Problem, Solution, Remaining tasks. Are those distinct fields or a template (or did you not tackle that question in this design)? I feel like the separation/hierarchy of those 3 elements is likely to get lost if the Problem contains lots of HTML (especially if it contains an h3 or h2 tag in that html).

@greggles I did not tackle that part, I just did what we do now - putting the template in the body of the summary.

How about making sidebar little less heavy. I've also added updated information, update and add comment buttons and leftovers of "jump to" links on the right.

Maybe it makes sense to move files and commits to the left, because page will look really weird with short issue summary, especially when expanding all files/commits. Also it will be possible to place more information into listings. If collapsible boxes will be expanded by default maybe better to use tabs?

I am not sure if comment filtering "Only commits" is needed - will it not just duplicate commits listing? only in reversed chronological order.

Displaying v5 of the issue node wireframe.

added a section for related issues

added link to #1559578

I really like where #65 is headed. Thanks!

However, if we're going to use this issue to dream big, here's a potentially crazy idea that came to me tonight while thinking about #1553546: Encourage issue queue participants to clearly formulate the problem separately from proposed solutions, #1559578: D7 solution for when multiple users are updating an issue simultaneously, and sort of #1549280: Provide an explicit relationship between patches and comments about patches, too...

If we're going to have a separate "Solution" text area field, we could make that multi-valued. ;) So, if there are multiple proposed solutions, they're entirely separate fields (not just templates and convention to label the separate solutions in a single field). It's totally obvious to everyone that they're distinct, we could easily theme them so that they were uniquely identified in a standard way so everyone can refer to them directly in their comments, etc.

And if we're going to go that far, maybe we should make the solution a multi-valued field collection. In addition to the description text area, we could have an optional title, multi-valued file upload, and perhaps even version and status. ;) We could bury all of this other stuff by default, but reveal it for advanced issues where you might want to be tracking different patches for different backports (each in a different status), or where you have different proposed approaches to a given problem, each with their own screenshots and patches, etc. Furthermore, each solution could be edited independently from editing the entire issue (field collection provides edit pages for each collection entity), so that would somewhat mitigate the problems of people updating issues simultaneously and getting form submission conflicts. Separate version fields associated with each set of file uploads also seems like it'd help the testbot know what branch to use when testing a given patch file. And in the world of per-issue Git repositories, we could have some magic to associate different branches in the issue's repo with each solution entity.

In fact, couldn't we even allow comments directly on each solution entity? ;) You could still just comment on the whole issue, and we'd still want an interlaced view of all comments across all solutions, but you could also just read the discussion related to a single solution if you wanted.

The issue itself would still have a "master" status and version, visible in issue queues, etc. But you could drill down and get a higher resolution picture of what's really going on when you view the issue itself. Maybe we could even expose the solutions into the issue queue views in some way (could be just a count, or even details of each one if we can find a way to make that not totally overwhelming).

Obviously we'd need to design how to render the separate solutions when viewing an issue. But it seems pretty natural to still have the issue title and description at the top left, the issue-wide metadata and action buttons on the right (just like #65) but then you'd see a section for each solution, displaying whatever data we have for each one (including its file upload table, if any). I guess we'd still want to allow files attached directly to the issue (e.g. screenshots of the problem). And, in simple issues, folks could just attach a patch there, too. But, generally, we'd encourage patches to be posted to a specific solution, instead.

Is this too insane? Clicking together a multi-valued field collection for solutions would be incredibly quick and easy, and it seems like it could solve (or at least help) a *lot* of our problems, especially in the more complicated issues. Yet, by default, you'd basically still just have the issue title and description, and maybe a single solution text area. One click adds another simple solution field. A different click expands a simple solution (just a text area) into an advanced solution (revealing all the other optional fields in the field collection).

Thoughts? ;)

dww - It sounds awesome. :)

#66 sounds like it has potential, but I start to wonder at what point we draw the line between what is needed for the D7 port, and what 'new features' could be implemented after the fact, given the new architecture? While I like some of the concepts you've presented here, does the separate 'solution' field mean significant changes compared to the base architecture ... or could it be positioned as a post-launch feature enhancement (as a means of easing people through the workflow changes which will be introduced via the d.o D7 port, relative to introducing them all at once).

@dww: You're contradicting yourself. In #61, you strongly denied the idea of embedding a multiple value field for change notices into the issue/summary. Now a multiple value field for solutions with even more complex logic attached to it is fine?

As mentioned in #58.3 already, a comment thread per patch/file initially sounds nice, but more than often, reviews on particular patches also contain comments that go far beyond the actual patch/file itself. Therefore, the idea doesn't seem to make the stream of information as well as the UI/UX any better.

Overall, #66 is based a lot on the idea of blowing up issues with more and more logic and fields within themselves. This can be an approach, but there's also the exact opposite approach: Separate issues for separate things.

In fact, our current development workflow rather follows the approach of separation. If two people have the same goal, but different proposed solutions, then we usually create two issues that "compete" with each other. All comments, files/patches, reviews, properties, etc.pp pertain to the particular proposed solution within the issue only. So instead of trying to account for everything within an issue, you're skipping all of that complexity and rather link issues to each other and generally aim to improve the "outside network" of issues.

(As a side note, we have a similar requirement and approach for meta issues.)

While I can imagine many use cases for multiple solutions, it's hard to imagine a UI for managing distinct solutions that would be simpler than multiple issues linked to each other, like we do now. For example, #7 linked to an alternate solution for this very issue. It's hard to see how having a solution entity with multiple solutions attached to this issue would make that workflow any smoother. What would make it smoother, I think, is simply putting that link in the issue rather than a comment, which seems to be encouraged in the current wireframes.

I'd like to see "follow" made less prominent. It's not directly part of any of the current user stories, and it's the most passive way to get involved in an issue. Based on the current user stories, I'd think "follow" should be even less prominent than "update" or "comment," but I think we're actually missing an important user story:

As a learner, I want to watch an issue's progress and learn how Drupal contribution works.

Even as a relatively active contributor, I'm probably following more issues just to learn than in any other capacity. I think between learners and site builders, there's good reason to keep "follow" at the same level as "update" and "comment," but I think making it more prominent might be encouraging passive watching a little too much. In the current wireframes, "follow" seems like the main thing to do. I'd like to see it instead positioned as one of the options, but not the primary option.

I really like the wireframe, it's much clearer than the previous one. My only suggestion would be to make the Follow button a bit more obvious, both position-wise and color, having it tucked underneath multiple items in the sidebar and a grey color just feels like it's being hidden.

While @dww's ideas sounds very interesting for the longer perspective, it would benefit a whole lot of other situations greatly if we kept it at "separate issues" and instead of more fields and heavier logic, made http://drupal.org/project/comment_mover work well with both these needs and in general for other similar D7 content-management tasks. That is sorely missed in very many projects.

The sidebar layout in #65 looks great :-)

Hm. I've read #66 at least three times and am having kind of a hard time picturing it. I agree with others though that separate issues is generally how we handle divergent solutions. #44162: Relationships between issues: support for parent issue and related issues gets us a lot more bang from our buck, at first glance.

Oh. But the wireframe in #65 is *gorgeous*.

I really like multiple solutions as distinct "things" because we can vote on them and generally break stalemates. Stalemates are the key barrier to faster growth for our project ... We don't have to tackle it now, but I do think it would be valuable.

added #1628042 and #1628044 to the related issues

We really need to move this forward. I had a long conversation with Senpai earlier today and we came to some initial decisions:

• Let's not split out a separate field for solution vs. problem as part of the initial launch: #1553546-6: Encourage issue queue participants to clearly formulate the problem separately from proposed solutions.
• Split off #1628042: Implement the "Update this issue" button when viewing an issue to a separate issue so it can just be implemented -- we clearly want/need that.
• Split off #1628044: Implement magic for the table of attachments on issues to a separate issue so it can be implemented, although that probably needs a bit more fleshing out and discussion.
• Split off #1628122: Implement table of current issue metadata values when viewing issues to a separate issue so it can be implemented, although that probably needs a bit more fleshing out and discussion.
• Updated the summary at #1545952: [META] UI for updating an issue in D7 and posted comment #31 with our latest thoughts on that.
• Split off #1628160: Port issue nid field formatter to D7 to a separate issue since it would be a big help towards allowing us to easily work on #44162: Relationships between issues: support for parent issue and related issues

I just noticed this issue, and am really excited for it.

My one suggestion is to consider Editable Fields as an alternative to updating issue status and other fields via comments or forcing users to fully edit the node. I'm not sure if you could associate log messages with changes to fields though.

@Dane Powell: thanks for the suggestion. We're hashing out the details of the issue update UI over at #1545952: [META] UI for updating an issue in D7. Editable Fields looks like another possible way to implement the "In place editing" proposal already being discussed there. If you want to update that issue summary with a link, that'd be helpful.

Cheers,
-Derek

I really like #62 better. feels more right to me.

adding more subtasks

added #44162 if we can get to it...

added #1632492

From what I see in the dev site, the "Issue Status" details block limits the width of the entire page and thus causes it to be too long and require extra scrolling. Can we have it be besides only the issue summary so that the rest of the comments expand full width?

@klonos - I actually like how the comments are contained a little more in the design. I was disappointed when the current live iteration of bluecheese was launched, and comments went full-width. It's harder to read such a wide row of text, at least to my eyes.

...just a few related issues (specific to the attached files list and #1628044: Implement magic for the table of attachments on issues / #1833684: Need a file widget that gracefully handles lots of hidden files):

#1964094: Discuss positioning of 'Show Hidden Files' toggle on file upload widget
#1964202: Display the number of hidden files next to the 'Show hidden files' toggle link in the file upload widget.
#1245508: Issue summaries: Allow outdated attached files to be hidden/replaced/flagged.
#1956166: Auto-generate interdiffs between patch files (from patches uploaded previously).
#1955854: Group together files posted in the same revision.

moving sub-issues specifically for this into the "Remaining tasks" section, ripping out references to edit UI subtasks

Note: I just updated the issue summary based on a lot of recent progress related to handling file attachments:
https://drupal.org/node/1545922/revisions/view/2432364/2640664

This is getting pretty close to "done". We definitely still have some bluecheese work to do, and the d.o test sites don't look like tvn's mockup yet, but functionality-wise, we're almost here.

Seems that editing the issue summary is locked for this issue. In the "User stories" section shouldn't this:

As a patch reviewer, I want to use Dreditor to insert my code review and change the status to ‘needs review’.

be:

As a patch reviewer, I want to use Dreditor to insert my code review and change the status to ‘needs work’.

Updating the summary based on recent work related to file handling for issues, and using tvn's mockup from comment #65

Fixed the typo and reset the filter to "Filtered HTML". Not sure why it was on Full before.

Thanks for pointing these out,
-Derek

fixed typo in dreditor patch-review user story and set this back to Filtered HTML (thanks klonos in #87 for the tip)

.

.

.

.

.

corrected stale details about "revision log" field, added section for completed tasks so we don't loose track of everything we did for this issue.

actually fixing revision_log. ;)

tagging

reorganized remaining tasks into blockers and wish-list and added a mockup heading

Any chance of adding email notification to issues? I think it greatly enhance the experience and speed up the development process. we are all busy with our jobs. getting a notification about an important issue I subscribe to, is a very valuable functionality.

@Hadi Farnoud: See #1560012: Port per-user issue notification email functionality to D7 about that. We've had email notifications working for years, and are definitely going to continue providing that functionality.

added ol for better readability and minor edits

added 1972686

Can somebody provide a link to the latest dev site so we can see where we're at? Thanx in advance.

adding 1974560

upd.

During the last week dww, Bojhan, yoroy and I have been working on the final details for the issue page UI.
Remaining work split into the following issues:

• sidebar design/implementation #1977594: Issue page: sidebar
• issue changes on comments #1974560: Improve node changes layout on comments
• files display on comments #1760658: Come up with a formatter for file fields

@klonos, http://git7site.devdrupal.org is our main staging site. Use drupal/drupal to access it and your usual username/pass to login. That site can be broken sometimes since it's work-in-progress, but it's the best place to see where we are at. Note also that it is being rebuild every day at 08:00-09:00 UTC, during that time it is inaccessible.

Attached is the latest mockup (issue without any files attached). Updating issue summary as well.

adding 1977594

latest mockup

.

@tvn: yeah, thanx! I was merely asking in order to add the link to the issue summary (which I just did) so that others can also have a look at the progress.

...adding link to dev staging site ;)

added 1979000 as a blocker

#1974560 is now fixed --dww

#1760658: Come up with a formatter for file fields is fixed, and both it and #1974560 are now in bzr. -- dww

added #1979574 and moved a few to completed -- dww

Yeah but that's not exactly what I meant. Would be nice to be able to choose email option for each issue individually. the current email notification is not great. it simply sends every comment to your email. no daily digest option.

as a result, most end up disabling email notification. which isn't good for speedy dev

Hadi Farnoud: A complete redesign of the email notification functionality is out of scope for the initial launch. But we'd like to do that soon after Drupal.org is running D7. See #2005712: [META] Redesign issue email notifications for more.

The last blocker issue here, #1979574: Testbot info display on issues is just minor non-launch-blocking changes.

The best places for future work is https://drupal.org/community-initiatives. Within that, https://drupal.org/community-initiatives/drupalorg/drupal7 has links to various tags we use to track issues.