The Issue summary should augment the original post, not replace it

I agree with all this.

The idea of an issue summary is *definitely* a good one, but the implementation needs more thought.

- we don't want to lose what the original poster wrote
- we need to see what has been changed in the summary. I don't know who has access to edit, whether it's authenticated users or maintainers, but even if the latter we need to be able to revert in case of misunderstandings.

I not sure how best to do this though. One thought I had is this:

1. Alice creates an issue:
- Her original text is saved as the first comment on the issue.
- the issue node is initially blank, or filled with automatic boilerplate text

2. Bob edits the summary: Alice's initial post is unchanged, and the summary can be changed at will.

This would require some presentation tweaks so we understand the summary is one thing, and the initial post is another.

Also, it doesn't help with existing issues, where we can't add a new comment at the start of the list without breaking numbering and links.

Any other ideas?

Upping to critical -- I fear we are losing stuff here.

(BTW: is this in the right component?)

Proposal 2:

Add a CCK text field to issue nodes for the issue summary.
Lock down the node body to admins + node owner.

(If that's tricky with permissions, we could flip that so the node body is the summary and the CCK field is the original post but that would mean migrating data on all existing issues. And I guess we have the custom d.org module where we can invent permissions and set #access on the issue form.)

I just wish to point out that the issue summary standards instruct users to retain the original post when creating summaries:

<h3>Original report by [username]</h3>
// Text of original report here.
(for legacy issues whose initial post was not the issue summary)

Furthermore, no data is "lost." At worst, if someone incorrectly deletes the original post, it is available on the revisions tab.

Also, this may be a dup. of #1217646: Tweak UI of issue summaries.

First, the original post is NOT an issue summary. It should NOT get the "Issue Summary" title.

Note that this may be the case for some issues, but most issues I create have the issue summary in the original/opening post (node body). I expect most new issues to be kick-started with a proper issue summary, especially as we continue to improve the UI/UX along the way.

If it is a policy to never change the original post but add to it, then is there a good reason to not technically enforce this policy by making it a separate field?
The only reason I could think of is the possibility of inline annotations in the original text.

Having a separate field for the summary would also make it easier to spot changes: you only need to look into the summary text, not the original post text.

> Proposal 2:
> Add a CCK text field to issue nodes for the issue summary.
> Lock down the node body to admins + node owner.

I think that's the reasonable way to do it.
And the summary should be blank at the start.
The body can be made to look like a comment, but it does not have to be a comment technically.

I simply had no idea what was going on with this until I read this post. The data *is* (sometimes) lost, if I can't see it! Great that it remains in the DB/revisions tab, but what use is it there?

A great deal of the usage of the issue queues for site builders is "can I find an issue that matches the description of the problem I'm facing". Without this initial description, this is made quite difficult. Do also please consider that SERPs are a reflection of what users search for - sometimes that has to be "I can't find my view :( " and original content can be key in that regard.

I concur that a (technical?) summary post accompanying the original post would be fantastic, but it needs to augment, not replace, in every instance.

I simply had no idea what was going on with this until I read this post. The data *is* lost, because I can't see it! Great that it remains in the DB/revisions tab, but what use is it there?

See #1217646: Tweak UI of issue summaries. The intention, I believe, is to iteratively improve the UI to avoid this confusion.

The key point is that the data is not lost. It is just harder to find if someone updates a summary improperly. And it's easy to add it back into the summary if someone mistakenly removes it.

A great deal of the usage of the issue queues for site builders is "can I find an issue that matches the description of the problem I'm facing". Without this initial description, this is made quite difficult. I concur that a summary post accompanying this would be fantastic, but it needs to augment, not replace.

Actually, the very first header in the summary template (Problem/Motivation) should exactly match "the description of the problem [one is] facing." It should make it easier for site builders to find information by standardizing what appears there.

+1 to leaving the original post. Comments may/will refer to this original post. Replace it, and the structure of the discussion will get lost.

Demonstrating how an issue summary should not delete the original post.

I added an issue summary to this issue summarizing the issue summarizing issue (and demonstrating the correct format for an issue summary, retaining the original post). :)

Revamped issue summary.

Missed a phase.

Typo.

I apologize. I was not trying to "spin-doctor" anything, nor to give offense. I did not in any way alter your original post and I did not intend to criticize you in any way. Edit: I was just attempt to demonstrate how issue summaries are supposed to work, since everyone in this issue seems to think the original post is supposed to be overwritten, which is not the case.

Edit: Also, in case there is confusion: I am not in any way responsible for this feature nor affiliated with drupal.org. I am just trying to help clarify why it is the way it is now: The feature is an interim solution and improvements are already being made. See #1217646: Tweak UI of issue summaries.

I've edited the summary to replace a poorly chosen wording. Again, my intent was not to criticize anyone. The fact that people are not finding the issue summary instructions is a problem, not with those people, but with the design of the feature.

Hi xjm, thanks for helping out here. You're trying hard to understand the problem and describe it in an official issue summary. However, considering salvis' response, you fail. The result is that people coming to this issue will probably miss the point, as salvis' original report is buried somewhere in the issue. Leaving salvis feeling like he is not being taken seriously. Which I think is the underlying problem.

Suggestion: perhaps the Original report should be put before the Issue summary?

considering salvis' response, you fail

Yeah, I noticed. :P

Suggestion: perhaps the Original report should be put before the Issue summary?

I think this is a very reasonable suggestion, and since it's purely a procedural thing, it's a change we could make to the process without needing to wait on any technical limitation (which, as far as I understand, is part of why the feature has been rolled out as it has). I've also been meaning to suggest adding HTML IDs to the headers in the summary so they could be linked directly. If the original post remained first, and the summary were appended, one could easily add "Jump to" links for the summary and original report.

Obviously, the ideal solution is to improve the UI so the different types are separate, but that would take time to implement. What do others think of gaele's suggestion as an interim solution?

Folks, let's dial down the defense-o-meter, ok? :) If you feel you're being misrepresented by an issue summary, change it! That's what the edit tab is for. :) xjm meant no harm.

So, some comments:

1. I definitely agree that depending on humans to preserve the original post via RTFM is asking for trouble. The current solution was merely intended to be the simplest thing that could possibly work, so that we could get the feature rolled out, and then iterate on it further with the advantage of having issue summaries as a tool to help. :)
2. I was going to write up this long spiel about how an issue summary in a CCK field wouldn't work, and has killed this initiative at least once, because there's no way to edit a CCK field from a comment provided by Project issue module, unless we do special handling for it, or else replace the entire mechanism with Comment Driven, which DamZ doesn't like, which...

   However! In the current solution, you can't actually edit the summary from a comment either, so it's not like we'd be missing functionality that way. So this might actually be a good approach.

   We'd need to test to determine whether or not Diff module picks up differences in a CCK field, and then we'd need to do some light UI work to make the summary/body clearly stand out from each other, and then prevent people from editing the body.

Seems to me like the best approach is to work with some of the UX team and come up with a spec on how this should look, then for folks to start writing patches. You can grab a copy of the code to hack on locally at http://drupal.org/project/drupalorg_testing (I don't think this issue summary stuff is part of the install profile so you'll probably need to manually turn on issue revisions and set the perm -- patches welcome!), or you can apply for a drupal.org staging sandbox if you want to be responsible for driving this.

If you want to discuss scratching the feature, or making it optional, please open separate issues for that. Let's stay on-topic here. (But I am happy to speak passionately about how absolutely central this feature is to scaling our community's ability to solve problems.)

Tagging as "Needs design", to bring this issue to the UX team's attention.

This shouldn't be considered more critical than #1217286: Posting a comment changes too many issue node revision properties -- IMHO that's a more enormous bug in the existing UI. Downgrading this to 'major' since drupal.org is still functioning. ;)

Anyway, I just posted #1217286-60: Posting a comment changes too many issue node revision properties which is a rough proposal based on my attempt to understand all the problems with summaries that went live while I was offline. It tries to synthesize input from #1223538-5: Make the new Issue Summary optional per issues queue, #1222082: Move Issue Summary text elsewhere, #1217646: Tweak UI of issue summaries and others. It basically supports what I understand this issue to be about -- the OP and summary should be separate fields. I completely agree.

Rewording because apparently the original wording was open to misinterpretation.

This is an old stale issue. Can we close it? The issue summary mechanism is quite a bit different now than it was when this was being debated.

...yeah, we have revisions and nodechange comments now.

...related: #2181901: Remove the "Original report by ..." section from the issue summary standards template.