On 25 Dec 2008, at 13:19, Hanno Schlichting wrote:

* Bug
* Feature request
* Plone improvement proposal

I think bug and feature request are quite self-explanatory.

Indeed. It was only the third that requires/d explanation.

We tried to use 'defect' instead of 'Bug' for a while without success.

I prefer 'Bug'.

(Something that transpires to be _not_ a bug in Plone can then, simply, bug the user ;)

* use the expression 'Plone improvement proposal' in lieu of PLIP.

We tried that and it failed.


People don't read documentation up-front

I first imagined a small question mark icon (for a window to help/ explanation), alongside the 'Type' menu, but did not suggest it. I don't know whether Trac is extensible in that area.

but will go ahead and add new tickets. Once we had both "Feature request" and "Improvement proposal" in the list, people started adding the latter.

I did the latter, just once, and received a perfectly courteous response, plus some direction, and was happy.

pain to reclassify the tickets.

Pain ... to the person who does the re-classification?

As long as we cannot put security restrictions to the type of ticket you are allowed to add,

Plone trac feels very graceful and inviting, I would be against such restrictions.

the protection an unknown abbreviation like "PLIP" gives us, seems to be the easiest way.

That's fair.

Adding PLIP's requires you to know about the process involved. We need to better explain this process,

No rush for the (revised) explanation of (revised) process.

but we don't want random noise in the tracker.


---- (line of separation) ----

The entire feature request / ideas / feedback process discussion is separate from this, as it is directed at a different audience and needs different tools.

Sure. I think I already weighed in somewhere sometime about _not_ offering too many paths to feedback. AFAIR part of that discussion was to _not_ have commenting available in certain situations.


Framework-Team mailing list

Reply via email to