On 25 Dec 2008, at 13:19, Hanno Schlichting wrote:
* 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/
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
the protection an unknown abbreviation like "PLIP" gives us, seems
to be the easiest way.
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