[Framework-Team] Expression 'PLIP' in Trac - understood and agreed

Graham Perrin G.J.Perrin at bton.ac.uk
Thu Dec 25 21:56:07 UTC 2008


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.

OK

> 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.


+1

---- (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.

Best,
Graham




More information about the Framework-Team mailing list