Ticket Structure/Details of tickets/Update Template

[ftm1000]

Discuss structure and details of tickets i.e. how much information is needed, what is too much information, should we create updated templates etc Brainstorm structure of different templates eg - bugs (requires investigation)

• item of work (has a context, some design, motivation, etc)
• . Some people want more information, some less. We wanted to cut down on the detail in the past. Details also get out of date. We might need to check the level of detail when a specific person gets assigned.

[conradoplg]

My take on the current "feature request" template:

• Motivation: OK
• Specification: it's not that relevant now that we implemented most of the spec. But we can leave it.
• Design: it's not clear if this is limited to what the comment talks about (i.e. link to a RFC) or just design in general. We could make that clearer in the comment.
• Related Work: OK

And I think that misses the most important part: what actually needs to be done. I usually put that in Motivation or Design, but I think it should have its own section after Motivation. Not sure what to call it, maybe "Specification" or "Tasks"?

[teor2345]

I'd like to split out different ticket templates for:

• Consensus Rule Change
• Major Design Change
• Bug Fix
• User Issue Report

And maybe others, but that would be a good start.

[mpguerra]

closing this as stale