Encourage use of issue summary template

We have a "bare" summary template at:
http://drupal.org/node/1326662

http://drupal-association.ideascale.com/a/dtd/Add-issue-summary-template...

The problem with adding this to bueditor is that it's a button that only makes sense if you're on node/(add|edit) for a project_issue node. That button doesn't make sense on comment bodies, nor book node pages, etc, etc. AFAICT from poking around in the bueditor admin interface, even though we could define separate editors with different sets of buttons, there's no reasonable way to say "only use this editor on node forms for nodes of type foo". You just get a "visibility" fieldset where you can use paths with wildcards.

Searching the bueditor issue queue uncovered this gem: #333583: Editor by content type (warning, it gets ugly). Apparently, there's a hidden way to get this working, after all. However, I don't have time to actually try this myself and verify if it all works as expected. But, if we move forward with this (which seems like a good idea) then I think we're going to want to define a second bueditor definition for issue nodes themselves and add this button there...

Cheers,
-Derek

See also #962900: Patch to use the editor branch 2 by content type

There are two solutions:

1- Two editors with different path visibility settings

The editor with the issue template button. (Why the second path)

node/add/project-project

The other (set as alternative editor)

node/*

2- Single editor with a conditional PHP button that checks if the current page is an issue page.

Button content:

php:
$node = arg(0) == 'node' && is_numeric($nid = arg(1)) ? node_load($nid) : FALSE;
if ($node && $node->type == 'project_project') {
  return 'js: alert("This is supposed to be the issue template button that should appear on only issue pages.")';
}

are issue summaries going in as part of the D7 upgrade maybe?

@YesCT: I'm not sure what you're asking. Please clarify your question. Do you mean a separate summary field on issue nodes on d.o? No, that's not currently slated to happen as part of the D7 upgrade.

Thanks,
-Derek

Well, we have the issue summaries already. So my question was about having an easy way to get the issue summary template into that.

I thought that this might be being addressed as part of an issue with the D7 upgrade. So I was hoping for an update or a link to another issue.

Would this be best to wait on that upgrade and then try and see how to do this?

If you want to know how the D7 port of project issue is supposed to work, the best place to read is probably #1545922: [META] Issue page redesign.

No, there's not going to be a separate field for summaries, and there's not going to be a default summary template when you first create a new issue node. I think a bueditor button to inject a default template for folks that want that is still a reasonable idea, could be developed and deployed now, and wouldn't really have to be changed once d.o is upgraded to D7.

Cheers,
-Derek

Thanks Derek. :)

I proposed #2006256: Configure the default body field on issue node creation to provide the "issue summary template", but was pointed here. I'm not as familiar with BU Editor or how d.o uses it, can someone point me to the repo where our settings/config are?

I don't intent to derail the task of upgrading d.o to D7, but I'd like to take this chance to ask if it was ever considered to move to Spark once the upgrade is done. I'm asking because perhaps then putting effort to doing all this for BU Editor wouldn't make sense. Just saying.

quotes from IRC

Would this work as the default value for the issue summary field?

oooh. I think so.

[edit:]
A button might still be useful, for when editing old issues and (inserting) updating the issue summary.

We should start exporting project* content types as Features, so we have a place to put this sort of thing in code, including Drupal.org-specific things like this. The patch for this issue should be an exported issue Feature.

This issue was submitted to the GSOC project https://groups.drupal.org/node/455978#project32

We should start exporting project* content types as Features

This was done some time ago. Setting the default value will be straightforward.

tagging since dreditor has the template buttons and we want to move that to d.o

I have outlined quite a few issues with how Dreditor currently does this and why "fixing" it is going to be problematic: https://github.com/dreditor/dreditor/issues/253#issuecomment-98425848

I would really prefer this be something that is moved over as a native d.o project_issue feature. The current mix of using a d.o node as "template" is very hack-ish.

Considering that issue summary's are really part of project_issue (or at least any sort of "template" would be) I'm moving it over to that project. I think providing more of a generic "issue template" system that could be easily configurable on any project would be far more preferable (as core and contrib practices differ greatly).

Also, when I say "issue template" system, I mean that each project should support multiple templates. Core currently has two templates used by Dreditor: Bare issue summary and Drupal 8 beta phase evaluation template.

updating the summary with the issue summary template. heh. using dreditor. heh.

adding note about per project setting to the summary

Trying to add #1115636: Issue Macros and Templates into dreditor (started on April 4, 2011) that ended into a 'not the perfect solution' rejection. This issue (January 4, 2012) is old too. Why can't we decided to have just A 'working' solution?

In that effort I used (child pages) of https://www.drupal.org/node/1120672 to get to projects which was lame.

• I agree on not using any node so we need a new content type 'template' with entity reference to 'project'. It should have a few properties like use for body / comment and being a prepend / append / overwrite type
• Now a project can have as many templates it needs.
• Using the new JSON API we can easily grab project specific templates but should have a default set too to make all projects being template enabled.
• Using BU Editor sounds like a decent solution.
• I think it is OK to have a drop down list similar to BU Editor 'Help' to select the templates available so this needs max to buttons (one for issue summary and one for comments).

This would not much deviate from current Dreditor injection I guess but could do the job.

This isn't going to work just as a default value for the body field, since we need different templates (or none) for different projects.

@dww what would not work with a node type 'template' with entity reference to a project?

https://www.drupal.org/api-d7/node.json?type=project_template&field_project=3060 should do the job I guess

Current templates are:

Bare issue summary template
https://www.drupal.org/node/1326662
https://www.drupal.org/api-d7/node/1326662.json

Remaining tasks template
https://www.drupal.org/node/2272209
https://www.drupal.org/api-d7/node/2272209.json

Drupal 8 beta phase evaluation template
https://www.drupal.org/node/2373483
https://www.drupal.org/api-d7/node/2373483.json

I just meant in terms of fixing this issue by means of a patch to the Feature module that defines our project_issue node type on d.o directly via the core Field API settings for this field instance. Surely we can form_alter() the node form and provide a #default_value by dereferencing an entity reference on the corresponding project node. I'm just saying this will require custom code, not merely Field API settings.

Anyway, the closer this comes to reality, the more sure I am that it isn't something project_issue itself wants to be in the business of providing. Project_issue is already complex enough (and then some). I don't see any reason to make this any harder by trying to make it generic enough to satisfy other possible audiences of this module. If people are really excited about this, let's find a reasonable way to support it on d.o. If it turns out to be generally useful and other people want something similar, we can use the lessons learned and perhaps generalize it later.

Thanks,
-Derek

I'm tagging this to show up in related work. I agree that we could role this as a D.o specific feature.

Do we want the same template all the time? In my experience for the drupalorg project, the template is a bit too heavy, and could use a link to https://www.drupal.org/node/1018084 and a deployment section.

The template could be a field on projects, like the list of components. Then the issue body would default to the value of the project's field.

Do we want the same template all the time?

We definitely do not. Indeed, the core template is often not too helpful for Drupal.org specific issues. Even between D.o issues - D.o customizations, Webmasters and Content could use quite different templates. Field on projects sounds good. Now some of the projects could use different templates per Component or Category, but that adds complexity..

per project template (with a sane default) would be great!

(and per project settings have been asked for on other issues, like response templates, and the issue about the needs tags/meta data which for a while was bubbling up suggested/official tags. so that would be a nice pattern to get established.

FYI, this issue needs to get flushed out and implemented on d.o relatively soon.

Firefox is/will be forcing our hand in Dreditor: https://github.com/unicorn-fail/dreditor/issues/256.

I have made the decision to simply remove the Issue Summary templates in Dreditor all together instead of trying to keep this weird relationship between d.o stored templates and Dreditor injection: https://github.com/unicorn-fail/dreditor/issues/262.

It appears CKE will be providing these templates now...

Now all we really needs is field(s) on a project that can store these templates to be injected into CKE.

If I may propose two suggestions here:

1. Drupal is a great content modelling tool for creating structured data, I don't understand why we'd use a (non-structured) rich text template for something as important as issue logging? Why not leveraging the tools in Drupal for improved meta data on issues?
2. Documentation seems to be missing as a task on the template discussed here. Adding it to the template will remind people to write some documentation before finishing a task.

"Bump". ;) This bubbled back up to the top of my consciousness since a recent change broke the 'Insert template' Dreditor button and now my life is miserable again. I looked at trying to add a 'Template' BUEditor button (before re-finding this issue) and now see that 8-years-ago-me was right and nothing's changed in the meanwhile. So I don't think that's going to be a good solution on its own.

We've got 1000s of issues without a proper summary, so we don't just need this when creating new issues. The dreditor functionality to be able to insert the template into an existing issue is golden.

Yes, the exact templates could be customized across projects. That's be slick. But anything is better than nothing. I'd be happy with a not-quite-perfect template that you have to remove a few things from, if that's the best we can do in a reasonable timeframe.

A lot of time has passed indeed and while nothing changed on the d.o issue queue a lot has changed with regards to open source project management.
Shouldn't we focus on moving towards a system that is more suited to manage issues?

I'd love to use gitlab issues, they offer templates.

This topic came up in #3157348: Meeting of the Bug Smash Initiative 2020-07-21 just now. We have a lot of bug reports without steps to reproduce. I suggested instead of more complex bespoke weirdness, we could simply use the core 'default value' feature of the body field on issue nodes so all new issues start life with a proper issue summary template. I thought I'd need to propose it here as an alternate, simple initial fix. Then I saw it's already mentioned in the summary:

• Use the template as the default value for new issues

So, as a bare minimum, let's start there. ;) We can patch the feature that defines our issue node type and already have an improvement. Let's not have perfect be the enemy of better.

Thanks,
-Derek

I'd like to support this method on adding a default template value to the issue summary mentioned by @dww above on #40 as well, for its simplicity and may be helpful in decreasing misinformation issues in the future.

+1000 :)

See also my old issue for adding steps to reproduce:

#2281761: Add "Steps to reproduce" section to "Bare issue summary template" for dreditor and default value for new issues

This incorporates the latest from #2281761: Add "Steps to reproduce" section to "Bare issue summary template" for dreditor and default value for new issues, too.

I made this patch on https://project-drupal.dev.devdrupal.org if anyone wants to try it there:

https://project-drupal.dev.devdrupal.org/node/add/project-issue/drupal

I notice we can probably remove the middle sentence from this help text, too:

Learn how to report an issue. Use the issue summary template in the Issue summary field below. Others can also change the summary.

Like so.

I would really like the template to be the default. It is something we can do now and get immediate benefit.

+1

Yes please - it's really annoying that Dreditor's insert template button is broken and this is a better solution that will not be as fragile.

This is now deployed on Drupal.org.

Hurray!!! Thanks everyone. :)

Fantastic, thanks!

I opened #3161070: Provide mechanism for per-project default issue summary templates to address the lingering concerns about per-project templates. RFC there for the proposed resolution. If folks are happy, should be pretty easy to get that working, too.

Cheers,
-Derek

This may need a bit of a tweak. After the commit, the default message at the top of the node/add/project-issue page says:
t('Learn <a href="/node/3156235">how to report an issue</a>. Others can also change the summary.'

This is a bit confusing, because the part about using the issue summary template was taken out, so the "Others can also change the summary" kind of doesn't make sense?

Maybe just take out the "Others can also change the summary" bit? The link goes to this page now:
https://www.drupal.org/community/contributor-guide/reference-information...
and it gives info about all of the issue fields, including the summary...

#53 makes great sense to me.

+1. OK, technically I didn't test it, but it looks right to me.

Cool. Committed and pushed to 7.x-3.x. Needs deployment.

Thanks,
-Derek

That’s now deployed, too.

Great, thanks again!
-Derek