Postponed
Project:
Project issue tracking
Version:
7.x-2.x-dev
Component:
Issues
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Apr 2012 at 03:32 UTC
Updated:
11 Sep 2012 at 21:11 UTC
Splitting this off from #1545922: [META] Issue page redesign so that doesn't get too insane. ;)
Problem
One of the things I got from various discussions with Leisa Reichelt about the Prairie Initiative and redesigning our collaboration tools is that our community suffers from submitting issues in the form of a specific technical implementation proposal for the fix, instead of clearly describing the problem. Often, the actual problem we're trying to solve is only implied indirectly -- given a specific technical proposal, we just assume people understand the problem. I do this myself all the time. Instead of the title and description of the issue explaining what's wrong, we talk about what we should do to fix it. Not only does this make it harder for people having the same problem to find the issue (leading to duplicates), it makes it harder to sanely talk about alternate solutions.
For example, my first instinct was to give this issue the title "Provide separate fields for 'Problem' vs. 'Solution'", but that's one specific possible solution to the more general problem I really care about. Maybe that's not the right approach. But we clearly have a problem -- people rarely name and describe the problem, they skip straight to their idea(s) of how to fix it. The point of collaboration in an issue should be to refine and clarify the statement of the problem, to brainstorm possible solutions, to refine those solutions and debate their merits, and finally to implement a fix to move things forward.
Solutions
A few proposals:
A) Separate fields for "Problem" vs. "Solution"
Even if we do this, there's already disagreement about what belongs in the "Solution" field. Some people assume that's just a curated summary of the final resolution. I disagree. I think that's where proposed resolutions should be enumerated and explained so that people can sanely discuss the options in the flow of the issue's comments and updates.
B) Separate section in the recommended issue template
Maybe we don't need a whole separate field, and instead we just want to revise our default issue summary template to try to address this.
---
If there are other proposed solutions, please add them here. ;)
Comments
Comment #1
mustanggb commentedI wanted to mention that although project_issue was designed and/or intended to be used at drupal.org it has many other applications. I know I have a few site ideas that are on hold for a D7 port that would make use of project/projust_issue.
So it might be prudent to bear in mind that if we do go the route of separate fields not to make them too Drupal specific. Alternatively if we can only come up with specific fields we should make sure to include and/or get working manage fields. Which might also be a nice to have with generic fields anyway, time permitting.
Comment #2
dww@akamustang: Indeed, I couldn't agree more. The only reason this issue is here in the project_issue queue instead of Drupal.org customizations is because I believe this might generally be useful to all project_issue sites. I'm extremely aware of d.o-specific stuff, and have spent many years trying to move those out of Project* so that those tools can be used on other sites.
I'm not sure what "get working manage fields" means -- in D7, the issue node type is just a core node type and *everything* is handled via the core Field API (and the "Manage fields" UI). You can have multiple node types that function as issue nodes -- for example, you could remove the "Category" field entirely and just handle that distinction with separate node types (although that would make it harder to move issues across the Category boundary -- e.g. "that's not a bug, that's a feature..." style replies). If I misunderstand your concern here, please elaborate.
Thanks,
-Derek
Comment #3
mustanggb commentedSorry, I was infact referring to the "manage fields" UI/tab, as you probably surmised. All I meant is that if possible could this functionality not be broken, e.g. We desperately need to get this patch in to get the issue code functionality that we need, but it breaks the manage fields UI, oh well lets just hide it and pretend the fields are hard coded.
No need, I think you made sense of it pretty well. You basically addressed my concern by saying that multiple issue node types and the fields API are fully supported. So I guess what I was saying basically boils down to, default fields should be generic for what is considered an "issue" and d.o specific fields should be separated as a d.o customisation.
Comment #4
dwwIndeed. If you haven't already, you need to read the Roadmap for porting Project* to D7 community initiatives page to get the context.
That said, I think separating problem from solution isn't a d.o-specific thing, which is why I'm considering it here as part of the default issue node type that gets generated when you install the D7 version of project_issue (which you are then free to alter in whatever ways you see fit if the default doesn't work for your needs on a given project management site).
Cheers,
-Derek
Comment #5
dwwI just posted #1545922-66: [META] Issue page redesign that expands on this idea.
Comment #6
dwwThis isn't a blocker for the initial launch and I don't want to delay things too much by making a dependency on this change. Although using a multi-valued field collection to store each proposed resolution is cool for various reasons, there are a lot of sticky complications with that. In fact, just splitting this off as a separate field at all will require more thought and buy-in and changes than I'm prepared to work on for the initial launch. We really need to be careful about scope creep on this initiative...
Marking postponed for now (although tagging as related to the d.o D7 upgrade). We can always reopen this when we have resources/bandwidth to make this happen, but it's not in the critical path...
Comment #7
senpai commentedUntagging now, because this is not going to get touched before the D7 site launches.