PROBLEM STATEMENT:
Very long issues are hard to grok.

SOLUTION SCOPE:
You may not add any code or make any configuration changes to Drupal.org

Comments

DrewMathers’s picture

DrewMathers CreditAttribution: DrewMathers commented

TRANSFER REASON: [Why this issue was transferred to a different queue]

PROBLEM PAIN LEVEL: Gone | Low | Moderate | High | Extreme

SOLUTION SUMMARY:
Provide the capability to have summaries near the top of issues through the use of guidelines for creating structured issue posts.

RELATED ISSUES:
Find all blockers [<a href="http://drupal.org/project/issues/search/project_issue?&issue_tags_op=or&issue_tags=this issue number+blocker"><strong>Find all blockers</strong></a>]
[Blocked by] <issue filter tag>
[Blocker of] <issue filter tag> (optionally add issue tag "<issue number> blocker")
[Duplicated by] <issue filter tag>
[Duplicate of] <issue filter tag>
[Child of] <issue filter tag>
[Parent of] <issue filter tag>
[Fork of] #1036132: Provide a mechanism for issue summaries
[Reference] <issue filter tag>

DrewMathers’s picture

DrewMathers CreditAttribution: DrewMathers commented

This is a Proof of Concept demonstration for creating project issues posts with summaries using only a set of guidelines that could be included in Drupal Documentaion.

Each structured issue consists of three parts

  1. The issue node containing the Problem Statement and Scope Statement (unchangeable)

  2. Comment #1 containing the summary (editable by the issue author)

  3. Remaining comments discussing the issue

The Problem Statement defines the problem and must not imply a particular solution. This is very important because the problem statement cannot be changed, but the solution ideas will evolve. Creating a good problem statement is harder than it sounds. It can be difficult to separate the problem statement from pre-conceived solutions. The 5 Whys can be used to refine the problem statement, or it may sometimes be necessary to create a prequel issue to define it. While this is arduous, a well defined problem statement will serve to keep the solution thread focused.

If at some point it is determined that the problem statement does not represent the real problem, then the issue should be forked, and a new issue created. Creating a new issue with a new problem statement does not necessarily invalidate the old problem statement. Both may be valid statements of different problems, and both issues may continue to separate resolutions.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Active » Closed (duplicate)

Going to mark this as a duplicate of #1036132: Provide a mechanism for issue summaries where this is being actively worked on for Drupal.org.

We went for a simpler, less overwhelming issue summary template at http://drupal.org/node/1155816 in the hopes that people would actually use it. :)

There's also an initiative to get related issues on Drupal.org, that's happening mainly in the http://drupal.org/project/pi_related queue.

Thanks!

DrewMathers’s picture

DrewMathers CreditAttribution: DrewMathers commented

This issue is an attempt to see how far you can push the issue tracker into the domain of a brainstorming tool. However, it may be preferable to let the issue tracker do what it does best, manage bugs, and go for a different approach, such as a wiki, for more complex endeavours.