Bug 706369 - specify boilerplate text for different types of bugs
specify boilerplate text for different types of bugs
Status: CLOSED DUPLICATE of bug 460258
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
3.6
Unspecified Unspecified
low Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-20 05:53 EDT by Noura El hawary
Modified: 2013-06-23 21:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-18 01:55:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Noura El hawary 2011-05-20 05:53:56 EDT
Is there a way to specify boilerplate text for different types of bugs?

For example, if someone was raising a documentation bug at the moment, they get this (software-centric) boilerplate text:

-----8<--------

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

------8<--------

While the above boilerplate is great for software, it is not so intuitive for documentation issues. Is it possible to substitute alternative boilerplate text for documentation components?

Suggested boilerplate below:

-------8<------
Document URL:

Section Number and Name:

Describe the issue:

Suggestions for improvement:

Additional information:
-------8<-------
Comment 1 Simon Green 2011-07-26 01:47:03 EDT
(In reply to comment #0)
> Is there a way to specify boilerplate text for different types of bugs?

Yes. See extensions/EnterBugComment/template/en/default/hook/bug/create/create-defaultcontent.html.tmpl 

> While the above boilerplate is great for software, it is not so intuitive for
> documentation issues. Is it possible to substitute alternative boilerplate text
> for documentation components?

Yes. However, how do we tell if a component is a documentation component? Do we want to change all documentation components anyway?

  -- simon
Comment 2 Jared MORGAN 2011-07-26 02:25:44 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > Is there a way to specify boilerplate text for different types of bugs?
> 
> Yes. See
> extensions/EnterBugComment/template/en/default/hook/bug/create/create-defaultcontent.html.tmpl 
> 
> > While the above boilerplate is great for software, it is not so intuitive for
> > documentation issues. Is it possible to substitute alternative boilerplate text
> > for documentation components?
> 
> Yes. However, how do we tell if a component is a documentation component?

I know that for EAP, all my docs components are referenced using a doc-* prefix. A while back I'm pretty sure everyone in middleware was told to reference their docs components like this in BZ to ensure they were differentiated from enterprise product components. 

I don't know if this is the case for Cloud or Platform docs writers.


>Do we
> want to change all documentation components anyway?
> 

I think having consistent bug templates for docs would be useful for product docs across all Business Units in Red Hat. The customer would see uniform and relevant boilerplate no matter what user guide they raise a bug against.

I've added Mike Hideo to the ticket so he can verify whether this would be a positive quality improvement move moving forward for docs.
Comment 3 Simon Green 2011-08-03 18:15:05 EDT
We discussed this bug in our weekly Bugzilla meeting today. This is a little more complex than the standard way we do different boilerplates since it is at the component level rather than per product.

We are thinking that we will use Javascript to handle changing the text box boiler plate.

  -- simon
Comment 4 Jared MORGAN 2011-08-03 18:20:15 EDT
(In reply to comment #3)
> We discussed this bug in our weekly Bugzilla meeting today. This is a little
> more complex than the standard way we do different boilerplates since it is at
> the component level rather than per product.
> 
> We are thinking that we will use Javascript to handle changing the text box
> boiler plate.
> 
>   -- simon

Thanks for the update Simon.
Comment 5 Simon Green 2011-08-18 01:55:51 EDT

*** This bug has been marked as a duplicate of bug 460258 ***
Comment 6 Simon Green 2013-03-03 20:42:58 EST
Just a note that this change will be implemented as part of bug 460258. If you wish to stay in the loop on this, please follow that bug.

Note You need to log in before you can comment on or make changes to this bug.