Let me start ny chiming in with _all_ the other user that have (or have had) a positive experience with pre-populating the description field.
My google-foo led me to this thread in pursuit of solution to the exact same problem.
The technical term for this kind of behaviour from the system is actually a very established concept, it's called NUDGING: https://en.wikipedia.org/wiki/Nudge_theory
In stead of _forcing_ users to waste time populating multiple fields (that will not later be used for structured queries), it's much more elegant (and effecient) to nudge users to remember to add the relevant information (or delete the template-generated content…).
Come to think of it - It's ___exactly___ the same methodology that's already being used elsewhere in other Atlassian product, EG.: "Confluence":
When you're using the templates for EG.: Meeting Notes, you see pre-populated text that you should replace or delete:
I wonder why it's a great idea there, but not in JIRA… :-)
PS.: I must say that in the cases where this does NOT work, it must be the _people_ using the issue-tracking-system that are in need of guidance.
NB.: I added that behaviour when using bugzilla many years ago and it worked brilliantly.
So please focus more on HOW to achieve it - as opposed to only argue WHY NOT to do it.
A helpfull nudge ;-) regarding why it might be considered bad practice is OK, but completely demeaning any other ideology is counter-productive
Brilliant answer. Not allowing a default value for a field, it does not matter how do you want to justify it with cheap philosophy: it is just wrong.
And yes, some people here are willing to use the default text as a placeholder, because Jira does not support that either.
It is just wrong that the "description" field is a magical field different than other fields which accept default values.
You can do it by creating custom fields.
In order to do so:
Click on the link 'Edit default value'.
After that, associate your custom fields to the screens in which you wish to have them.
Because it isn't pre-populating that actual data rather the information for the standard answers that need to be given on each issue that is filed. It is basically a template that MUST be filled out on every ticket. A gentle subtle ... in your face reminder of what is required to be in that field.
Ah, all the wrong answers as usual. If you pre-populate a text field, people will ignore it. If you need it to fulful a certain format, people will overwrite that too. Convert it to a set of fields, leave them blank (unless you genuinely do have solid defaults for them) and set them mandatory to force people to enter them and think about it. In places where people set text defaults, you find that between 60% and 99% of issues will have the defaulted text and nothing else (the more complex you make it, the higher the percentage as a general rule).
We use Bug issue types.
I want my testers to enter a standard format for bugs in the description of the bug. I don't want to add another custom field for something the Description of the bug should handle.
You cannot do this is acceptable.
You shouldn't because my arbitrary experience tells you not to isn't always acceptable.
STEPS TO REPRODUCE:
This should be available in Cloud version.
Trying to force users into populating many mandatory fields that are mostly - but not always - applicable, is a surefire way to make users enter pointless rubbish while cursing the stupid rigid form at the same time.
Pre-populating the description field, with a useful, helpful template that both reminds users of what they should be writing and assists with nice formatting works great because it actually makes the work of the user easier while still allowing the user to use a better format in special cases.
I know it works, not from personal opinion, but from personal experience with a team of software developers that I was leading. We used Default values for create issue screen which unfortunately isn't available for Cloud, only for Server.
Nic, you are entitled to your opinion, but don't presume to know every situation that Jira users have better than they know it themselves. Scriptrunner is great, BTW.
I have to respectfully disagree with you, Nic. I have been using the prepopulated Bug format listed above for years and both the testers and the developers love it. I've only had a few people overwrite it and correcting them was a great teaching opportunity.
I'm working with a client now that is having a lot of trouble remembering the User Story format "As a ___, I want to ____ so I can ____". I was hoping to prepopulate that into the Description field for them.
What are you trying to achieve by pre-populating the description?
I thought I was clear, maybe I wasn't.
We want the description field to be more guided to help adherance to convention.
We like the description field being a single searchable discrete field. Most users follow the format, but it would be great for training and onboarding to have an established format for them.
Why haven't you split that up into custom fields which do take defaults?
What use is a description people will just accept instead of putting good data into?
I don't think you read, or understand what I described. Each bug is unique. However the very basic outline of:
Steps to reproduce:
The format above is already being followed, but some users forget some times and new QA users have to be onboarded.
Why don't you just remove the description field if you're not going to ask people to think about its content?
That is one option. We're already functioning well and sufficiently, but I would like to improve and enhance our current workflow.
If this isn't the forum or place for these types of inquiries, could you please direct me to them?
the same as guys above, I have exactly the same need.
Pre-fill template while creating bugs:
STEPS TO REPRODUCE:
I am one of many of Team leaders who really APPRETIATE if JIRA allows us to decide which way is more suitable in our environment.
We do have separate fields for Environment, operating systems, type of tests and others. But there is essential need of pre-filling description field with a template of what-you-should-not-omit-if-you-are-describing-what-was-wrong.
Nic, I am very sad of you attitude. We don't want to inject code. We want the ability to pre-fill the description field. If there is an option in the field edit mode, it would be the best solution.
Your proposal maybe works from developers perspective, but absolutely doesn't work from team process perspective.
Let Jira is tool and we master the processes. Not in opposite.
Same answer - JIRA doesn't do this natively, so you have to hack it. I'm afraid for Cloud, there's no real way to do it, unless you start doing things with browser add-ons.
I'm glad it doesn't let you, because it's a bad way of doing things, simply because you end up with a lot of junk and defaulted values, but that is a different discussion, and explained in full above.
I just wanted to chime in here and say that in 3 separate companies I have introduced pre-populated fields and have not experienced the 60-99% problem Nic describes.
It works when your users see this as a time-saving measure that is there to make their lives easier, and they understand why you want bugs or stories to be written in a specific format. It doesn't work if you have untrained or disengaged people entering tickets.
On the whole, in companies with up to 100 JIRA users, this has worked. Where 'stories' and 'BDD acceptance criteria' were not relevant, we introduced a 'Chore' or 'Task' issue type that didn't have anything prepopulated.
From experience, hhere are the downsides to having separate fields and making those mandatory (something I have tried without success):
Basically, by insisting on 'hard compliance' through hoop-jumping instead of 'soft compliance' through guidance, you remove flexibility and make your reporting process less Agile and less efficient. Somewhere, the person managing the database can run a report where everything fits neatly within the lines, but overall the organisation suffers.
My 8 years of experience with managing JIRA across 3 organisations has taught me there isn't one 'true' way to do things. You need to figure out what works best and be flexible to meet the demands of the whole organisation, not just one subset of it.
In this case Custom Field defaults should serve nicely.
Really sad to see this blanket statement answer over and over without considering why people do it. I'm in the same boat, I want to make it easy for my users and gently remind them of necessary information. Nobody in my organization wants to battle with a complicated form when all they need is a few lines of text in a text template.
We do the same with our GitHub pull request templates: We have some pre-populated text that reminds the submitter to fill in information that makes understanding the issue much easier.
I'm not sure it's fair to say the reason people ask is not considered - I think it is, and I think we do mostly understand why people want to do it. There's not a lot of discussion on it, because the "why" is not the issue.
The discussion has spent more time on the problems it causes and why people like me have spent so much time cleaning up the mess it tends to make.
Nic - I think it's time to maybe consider that in this case you might be wrong. I mean, really consider it. Is it possible that your reaction, based on your extensive experience, is not actually relevant to the suggestion that people are making? That there's a use case here you haven't seriously considered?
In my 20 year experience with software project management at numerous Silicon Valley companies, there is no single step which is more conducive to good bug reports than the exact template that keeps getting mentioned in this thread:
STEPS TO REPRODUCE:
There's a reason so many people use this. It works.
Now I'm willing to be open minded too. Can you propose a design using custom fields or other available features in Jira to accomplish the same result without a default template for Description field? That when a issue is filed with type Bug, that the victim of the bug is gently nudged to structure their bug report in a way that is clear, systematic, and comprehensible to both developers and testers? That this structured observation still provides enough flexibility for users to bend it to their needs and the idiosyncracies of each bug, or ignored if it doesn't apply at all? And it is presented front-and-center where everyone who looks at the issue will focus on the most important characteristics of the bug? I am legitimately interested in your answer.
Allowing pre-populate fields helps people entering bug or issues according to a template. This also reduce the possiblity to forget something (though specific fields do as well).
On my side, one of the reason I would like that possible is because I work with populous teams that have minimal knowledge of Jira and I would like them to be able to search by keywords in the summaries and descriptions to prevent duplicates; the information exploded in numerous fields makes that impossible.
I want to do the same thing as other people have mentioned on here. Pre-populate the description with a template structure
Steps to reproduce
Hopefully someone will see that there are several people here that desire this functionality, and help us achieve it, rather than beat us over the head with their opinions about custom fields.
Put the following in the Description field and it does the trick. Ticket quality has improved substantially
I followed the basic from here: https://community.atlassian.com/t5/Jira-questions/How-to-pre-populate-a-required-field-on-issue-create/qaq-p/69257#311806
but used the following code.
if (document.getElementById("description").value == "")
var template = "*Steps to Test / Reproduce*\n"
+ "# goto http://replacewithurl.com\n"
+ "# [step 2]\n"
+ "# [step 3]\n"
+ "# [more steps as needed]\n"
+ "Replace this text, you can use attachment tool to inline screenshots\n\n"
+ "*Desired/Expected Behavior*\n"
+ "Replace this text\n\n"
+ "*Observed Behavior*\n"
document.getElementById("description").value = template;
One user mentioned it already, but here's the link:
Using "Behaviours" from the ScriptRunner plugin should exactly solve this request.
This does not work. It actually makes the problem even worse.
It does add a pre-filled description on creation of the issue. After you create it. Every issue done this way has the default text in the description, and users have no reason to go back and edit it.
No, people like Nic are tired of cleaning the mess made by this sort of poor design. I'm not trying to sell anything. In fact, if I were, I'd be encouraging you to do this because I know it generates "please clean up the mess" work for people like me.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot