Update the ticket life cycle diagram

[Ramiro Morales]

Now that r15665 has happened, we will also want to update the workflow ​diagram in the ​Ticket triage section. We would need help from someone with accesss to the right platform/tool (OS X/Omni Graffle?) and the source file.

[Gabriel Hurley]

As far as I can tell Jacob added that image in [4346]... quite a long time ago. At this point if the original isn't available we may need to just re-create it.

[Travis Swicegood]

Second pass at a new way of doing this

[Travis Swicegood]

I've talked with Idan about this. It spun off a whole long discussion about what this lifecycle should be, so by the time someone gets around to reviewing it, this could very well be irrelevant. :-)

[Julien Phalip]

Looks pretty awesome! I just had a few remarks:

• "Needs Info" is a resolution, which means that the ticket will get closed. The ticket may then be reopened if more information can be provided.
• In principle, no ticket in the "Accepted" stage would directly be checked in. In general someone first needs to review the patch and then move it to "Ready for checkin" before a committer checks it in. A rare exception to this principle is a committer jumps this step if he/she approves the patch and is ready to commit it right away.
• An free and open format would be preferable for the source file to make sure anyone can update it. Maybe SVG?

Thanks for the great work!

[Gabriel Hurley]

I'll second the suggestion of SVG... as much as SVG can be difficult to work with and has its own painful limitations I think it is sufficient for our needs and is one of the few open formats that's continued to have broad support.

Moreover, browser support is coming to a point where it would not be unreasonable to directly embed SVG into the docs as opposed to converting it to an image. This would require some minor hacks to support older versions of IE, but the tools are readily available and easily bundled.

Choosing a standard (such as SVG) for images in the docs and making sure we thoroughly support it would also go a long way towards making it easier to add images elsewhere in the docs as well (as per Steve Holden's talk on why the docs suck).

Lastly, SVG can actually be properly version-controlled since it's text-based, which is a big plus.

[Travis Swicegood]

Based on feedback from ticket

[Travis Swicegood]

I'm happy to export this as an SVG, but I'll need some help. It doesn't that OmniGraffle allows me to export directly to an SVG, but I do have a few vector options. Anyone got any ideas on EPS or vector-based PDF to SVG?

[Travis Swicegood]

@julien: I also chatted with Justin Lilly about this at the sprints -- he hadn't come up with anything in particular, so he said to go for it with this.

[Julien Phalip]

Nice! Just a few small comments:

• Clarification for "Needsinfo": the bug isn't necessarily rejected but there isn't enough info to be sure it's genuine. The ticket can be reopened if more info is provided.
• "Design decision" => "Design decision needed"
• "Accepted are going to be created" => something like "The bug is verified or the feature request is accepted as a good idea".

Regarding converting to SVG, I just found this via Google: ​http://code.google.com/p/graffle2svg/
Looks like that project is quite active so hopefully that would work considering the diagram is fairly simple.

[Aymeric Augustin]

Related: #19045.

"Fixed on a branch" must be removed from the diagram.

[Aymeric Augustin]

The latest version of OmniGraffle Pro allows exporting to SVG. I just used that successfully for two other images. A PDF version must also be included, because Sphinx' PDF builder doesn't handle SVG.

Travis, could you upload the .graffle file?

I'll review it, tweak it again :), make the SVG + PDF export, and commit the result.

[Aymeric Augustin]

Unfortunately we couldn't recover Travis' source file. I re-created the graph again. See attached file.

I tried to highlight more clearly the difference between "triage stages" and "resolutions", like the current graph does.

I only annotated the transitions that are up to the community — core devs don't need this graph.

[Aymeric Augustin <aymeric.augustin@…>]

In 9d62220e008c5e1b03e3026aaa97afac2e4eb67b:

Fixed #15516 -- Updated the ticket life cycle diagram.