Stopping the bleeding

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

I was talking to Leisa at DrupalCon about how this initiative fits in to various efforts to "stop the bleeding" on things that are obviously broken and need something done, even if they don't have the benefit of months of collecting user stories, synthesizing the pain points, exploring possible solutions, etc. She said she wanted to hear about those efforts, but not to be a gatekeeper for them moving forward. In her words: "A half-good solution is better than no solution at all". So, she suggested I opened a wiki page here to list specific changes we're planning/hoping to roll out in the nearish future, to at least keep this group informed of them (if nothing else, as more data about the existing problems).

Off the top of my head, these are the first two that come to mind:

Issue queue workflows

Finding out about things

I (or others) will hopefully keep this page updated as either other changes are getting ready to go live or are actually deployed. Please edit this page if you know of things that are about to be pushed onto d.o (or already were).

Otherwise, if you want to register something that's bleeding (or otherwise painful), please add a comment to exploring the problem space - where are the pain points? or start a new discussion in this group.



Cross posts

Steven Jones's picture

'Cross posting', really should get eliminated, because it's a total pain that I think we can deal with, but we just haven't bothered to do anything as far as I can tell.

So the scenario is that you are composing your comment and then one or more comments get added while you're still adding yours. This is fine unless you change some of the issue's properties, other peoples changes get changed back to what they were when you started creating your comment. There are three ways to handle this I think:

  1. What we have now, last poster wins, and no warning about what just happened.
  2. Flag up that there is a conflict, and force the user to re-enter their comment and change the properties of the issue to what they should be again
  3. Be very smart about it, and work out exactly which properties have changed, and offer the user the ability to review which properties should be updated to reflect the 'original state', 'current state' or 'proposed state' (and yes those are bad names.) Maybe a simple form with columns that list the properties and allow me to choose which value to 'merge' into my comment.

I'll agree that cross-posting isn't the biggest issue in the world, but since we're discussing changes to the queue, I thought I'd just throw it out there.

dww's picture

This is a well-understood problem with a patch underway: #218066: Prevent cross posting from reverting metadata fields.

Also, this post is not meant to be a place for people to express their pain points. That's what exploring the problem space - where are the pain points? is for. This post is specifically for people working on short-term fixes on d.o to record them so that folks interested in this initiative can be aware of the fixes happening in the short and medium term (and what those can tell us about existing pain points).

Thanks for your cooperation,

Per discussion in IRC, I

pwolanin's picture

Per discussion in IRC, I think this issue needs both a short-term fix and a longer-term discussion: Bot needs to handle patches named for all core versions -D[678]

Does this sort of stuff belong here..?

webchick's picture

From Leisa's talk, I wasn't picturing this group turning into a duplicate of the Project* modules' issue queues, and don't really see the value of that. I thought the Prairie initiative was for more over-reaching discussion of how we collaborate as a community, whether and how to introduce more "social" aspects into our tools, adding fine-grained personalization options to more readily get targeted information to busy people, etc. In other words, things that could really use a cohesive, brainstormy think-through by a number of stakeholders before leaping directly into implementation. But issues that are well-known, long-outstanding bugs ought to just be fixed. No?

By request from Leisa

dww's picture

As I tried to make clear in my original post, I started this wiki page by request from Leisa. I spoke to her for a while before and after the closing session of the conference. I explained that I was planning to keep making incremental improvements on some of the obviously broken stuff, and wanted to know if she wanted to be involved in those efforts. She said she didn't want to block progress, and that she wasn't planning to be deeply involved in reviewing the UX on any of those smaller-scale efforts. However, she wanted to know about them, and asked me to post them here so she could follow them without trying to follow everything in the Project* issue queues.

Unfortunately, other folks don't seem to read my initial post or my replies, so they're turning this into another place to make requests for things to fix. This is the 3rd time I'm asking them not to do that, we'll see if it works. ;)

This wiki page is mostly for me to communicate to Leisa about work that I'm actively fixing on d.o. Please do not post your requests for things for me to work on here. Post those in the appropriate issue queue on d.o if it's an actionable task, or as a comment at exploring the problem space - where are the pain points? if you just want to register your dissatisfaction with something but don't have a worked-out plan to fix it...


Apologies Derek, I read my

Steven Jones's picture

Apologies Derek, I read my own meaning into your original post. If you want to get a g.d.o admin to remove my post so that the idea that this is a place to submit ideas is further removed, then please do. Also, maybe get comments turned off for this post, as they are clearly not needed/wanted.

Prairie Initiative

Group organizers

Group categories

Prairie tags

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: