Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We've been doing some real-world testing of the new Issue Summary in #1221190: The Issue summary should augment the original post, not replace it, and we've immediately uncovered how this feature can fail.
As I wrote in #1221190-19: The Issue summary should augment the original post, not replace it:
Writing a fair summary is extremely difficult. xjm wasn't able to do it in ten minutes for a simple issue like this one. He put himself in a bad spot, even though he meant well, and he had to spend even more time to try to get out again. I don't think I'd ever try to do this in any of my issues queues, and I wouldn't want anyone else to do it there.
The situation is different for core issues that may run over hundreds of comments, but as sun mentioned, some people have already had the permission to edit issue nodes and create/maintain summaries, and they've made good use of that privilege. In the end I think we should just scratch this feature, or at least make it optional per issues queue.
We need to weigh the benefits vs. the costs, and I believe that these depend heavily on the project and the issue at hand. Every maintainer should be able to decide for him/herself whether s/he wants to bear the costs.
Comments
Comment #1
dwwDisclaimer: I've been offline for 2 weeks, and am only starting to catch up on all the issues I've missed since I was gone.
That said, I think that radically changing the behavior of the issue queues depending on what project the issue happens to be filed in right now is a terrible idea for the following reasons:
A) It's confusing to end users if they can't use a consistent interface for our issue queues.
B) WTF is supposed to happen when an issue moves from a queue with summaries into a queue where summaries are disabled?
C) It would require a *lot* of code to get this working. I'd rather see that effort go into making issue summaries work better so no one wants to turn them off.
Therefore, "won't fix"...
p.s. Disclaimer #2: I'm going offline again for another 10 days. ;) So, I probably won't be able to reply here again until after that...
Comment #2
salvisA) I don't think it can be any more confusing than what we have now — but I was told we're still working on it. It seems pretty clear that we need a cleaner separation between original post and issue summary, so that each can stand on its own ground.
B) How about nothing?
C) Since the whole concept is still being worked out, it's too early to dismiss this on the grounds that adding a simple flag to issues queues and issue nodes would "would require a *lot* of code."
Therefore, setting back to "active," hoping to discuss this in a constructive manner.
Comment #3
dwwA) I don't think you understand my point. Regardless of how confusing the current implementation of issue summaries is (and whether or not it's getting better), it'd be *even worse* if some issues had the summary UI and others didn't. Maybe not worse for you if you wanted to live in a bubble where the only queue(s) you look at turned them off, but worse for everyone else using drupal.org. As a maintainer of drupal.org, my "job" is to weigh the cost/benefit to the whole community for any given proposed change, not just isolated users.
B) "Nothing" is a completely insufficient answer. We'd have to do something. Please think about this for a few moments from the perspective of someone trying to use the issue queues, not as a maintainer that doesn't like the current implementation of issue summaries.
C) I don't want to brush you off, but you don't seem to be acknowledging that I'm the primary maintainer of all this code. Having thought about your proposal twice now, if I say "this would in fact take a lot of effort and code", it's not fair for you to dismiss that assertion on the grounds that your proposal is still being fleshed out. Even optimistically where you punt on B, what you're talking about is not a "simple flag". I could start to enumerate all the work it would take to make this "simple flag" a reality, but that'd be a waste of time that I'd rather put into making summaries better for everyone.
I'm trying to be constructive here and channel effort into things that will make life better for everyone. That said, I'll let someone else set this to "won't fix" so that it's not just me making unilateral decisions. But I'm strongly -1 to this proposal (in case that wasn't already clear). ;)
Cheers,
-Derek
p.s. For the record, I'm also not a big fan of the current issue summaries implementation, and there are a lot of ways it can and should be made better. I'm not personally attached to the current implementation and not defending how it currently works as The Best Possible Way(tm). I just think this proposal would make things even worse, not better. Hope that's clear.
Comment #4
salvisThank you for your well thought-out reply.
I need some time to follow up in an equally constructive manner.
Comment #5
salvisYour point seems to be that uniformity is bliss. Let's look at what we have now:
Why can we not just display an issue summary (with the "Issue Summary" title and maybe a CSS box around it) below the original issue node body, if we have an issue summary, and display the normal issue node (as before) if we don't.
I can't see how that could be confusing in any way and how you can say that this would be "*even worse*" than what we have currently, for anyone.
Nodes with a summary could have a prominent "Jump to Summary" link at the upper right (in case the body of the OP is long). So far for presenting the issue node.
In #1 you wrote
So let's talk about interaction: The only interaction element that has been changed is the Edit link that became available to everyone. I'll readily admit that this is a very cost-effective change, but it's too cheap, really, and it has a huge potential for confusion as you can see in #1221190: The Issue summary should augment the original post, not replace it, for example.
I would propose to add a local action "Add summary", available to everyone, that shows only on issues nodes without summaries. Clicking it would
I see absolutely no potential for confusion in my proposal, and I think implementing it should be possible in a few hours.
Having summaries disabled in a queue would mean nothing more than not showing the "Add summary" local action on the issues in that queue. Everything else would remain the same. If a node with a summary were moved to a queue without summaries, then it could well remain unchanged, i.e. keep its summary and "Edit" action. I see no problem there. If the node has gotten so many comments that someone thought it wise to create a summary, then it's perfectly OK to keep the summary (since it's implemented in a reasonable, non-confusing way according to my proposal).
I just don't think that the issues in any of my (and most other) contrib queues could ever become so complex that they need a summary, and I wouldn't want users to get into the habit of creating summaries for simple issues. Do you think that having the "Add summary"/"Edit" actions (the "summary UI") on the issues in some queues but not on most issues in the other queues would cause undue confusion? I've seen "Edit" actions on some documentation pages and not on others for years and I've managed to not lose my mind over this so far.
It seems that this can be done even without any flag. All that it requires is an additional text field (maybe with its own input format) to save away the original body (and act as the flag ;-)). Am I missing something? in the presentation? in the interaction? in the design? in the coding?
I fully acknowledge that you are the master here and that you know much more about this code as well as about Drupal in general, but to my limited mind my design looks like a relatively simple, well-defined task with very little side effects. I may well not see all the consequences and implications, but maybe you are too deep in your code to recognize a simple solution?
Best,
Hans
P.S. I realize that I went well beyond the scope of this issue, but I wasn't able explain my thoughts without actually fleshing out my ideas. I hope this can fall into the right place, and I'm sure it will take a lot more polishing before it's ready to roll out.
P.S. You don't need to reply exhaustively...
Comment #6
dwwSorry, we're talking past each other. You're documenting all sorts of UI problems with the current implementation, most of which already have issues about them. I'd encourage you to find those issues and contribute meaningfully to them.
The actual proposal you're making is to have a checkbox on project nodes that disables the entire issue summary UI on all issues in that project. That does not address the problems you're having with the summary UI, would require additional code, and would (continue to) drain volunteer resources away from just fixing the problems in the first place.
Sounds like your proposal is morphing into "make the summary UI not suck", which we all support and are working on elsewhere. Hence, I'm closing this proposal as a non-solution.
Thanks,
-Derek
Comment #7
dwwp.s. I linked to #5 approvingly over at #1217286-60: Posting a comment changes too many issue node revision properties. I think you've got a lot of good ideas in here. I just think this whole discussion is too fractured already, and the original proposal here to ignore the problems via per-project opt-out isn't helpful.
Thanks again,
-Derek
Comment #8
salvisThat's fine, thanks!
Maybe the original proposal here is moot because the new summary UI will be so nice that everyone wants to have it on every issue node :-), or the proposal can be resurrected later, after we have a couple of weeks/months experience with an improved UI.