Bug 706369

Summary: specify boilerplate text for different types of bugs
Product: [Community] Bugzilla Reporter: Noura El hawary <nelhawar>
Component: Bugzilla GeneralAssignee: PnT DevOps Devs <hss-ied-bugs>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 3.6CC: jmorgan, mhideo, sgreen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-18 05:55:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Noura El hawary 2011-05-20 09:53:56 UTC
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 05:47:03 UTC
(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 06:25:44 UTC
(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 22:15:05 UTC
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 22:20:15 UTC
(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 05:55:51 UTC

*** This bug has been marked as a duplicate of bug 460258 ***

Comment 6 Simon Green 2013-03-04 01:42:58 UTC
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.