Re: [Framework-Team] PLIPs in Trac

[Alec Mitchell]

On Thu, Jun 18, 2009 at 4:47 PM, Hanno Schlichting wrote:
> Hi.
>
> Where and how to manage PLIP's is both a matter of a defined process
> and some software supporting this process.
>
> One of the main driving reasons to move all Plone Core development
> related information into Trac, was to have one place to manage and get
> an overview of all relevant information. If we need to get an overview
> of where Plone 3.3 currently is, we can only answer this based on the
> status of certain tasks and bugs in Trac plus the information shown on
> the plone.org/products/plone page. If you need to later find out what
> small feature / plip or bug has been part of which release, it is
> easier if all this information is in one place.

One of the main reasons that I'm in agreement with Matthew on this is
that I don't think major roadmap type decisions on which PLIPs
ostensibly focus belong mixed in with bugs and random feature
requests.  Having the potential roadmap and its progress outlined
within the software release system makes more sense than having it
available exclusively  in an issue tracker that no one besides
developers bothers with (especially when it's cluttered with noise).

> Now when it comes down to the exact software features of Trac vs. a
> Plone content type, they are pretty much the same from what I can see:
>
> - Notion of ownership of the plip by a user
> - Assignment to a milestone / release
> - Unique ID
> - Short title
> - Full text description
> - Workflow state
> - Comments
>
> What is different about these two:
>
> - PSC has multiple text fields for various sub-headings, whereas Trac
> only has one text field and the structure needs to be defined by a
> template. The structure given by PSC has often been ignored, as
> there's too many fields with unclear separation.

I consider this a large advantage for PSC, and I think the results so
far speak to that advantage.  In PSC, it is painfully obvious to the
creator/editor of a PLIP when their work is incomplete, because the
ostensible requirements are a prominent part of the editing process.
We don't have that with Trac.  The structure provided by PSC may have
been ignored (or left incomplete) at times, but never to the extent
that we're seeing with Trac.

> - PLIP's in PSC can only be edited by members of the plone core
> development team, whereas tickets in Trac can be worked on by anyone
> with collective write access.

This is not a requirement, just a choice made in our deployment of
PSC.  It may in fact be a good choice, but it could easily be changed
to allow collective committers or an even broader selection of users.

> - There's a more sophisticated specialized workflow in PSC for PLIP's
> that doesn't match the reality. Usually I used to move things into the
> appropriate stages all the time, but the workflow was largely unused
> in practice. Since we upgraded to Trac 0.11, we can define a
> specialized workflow in Trac as well, that could actually match our
> process.

We have customizable workflows in Plone as well, I believe ;-)  If the
workflow is not correct, we can change it easily.  It's certainly more
correct than the complete lack of PLIP workflow in Trac currently.

> - Trac has the ability to let users subscribe to tickets via the CC,
> so you can get updates about the progress of a particular ticket.

This is certainly a big advantage for Trac and it may even outweigh
many of the above disadvantages.  Having to go back to the PLIP pages
constantly to look for updates would be a major pain.

> Following this I don't see a clear win on the technical side for PSC,
> but see Trac as more feature-rich and tailored to this particular
> need. Another reason to move things out of Plone, has been the
> particular slowness of plone.org. Commenting on PLIP's to cast votes
> has been an utter pain in the past.

I don't think you can reasonably say that Trac is more tailored to
this particular need than the system developed specifically for this
particular need.  I gather that commenting was a pain mainly because
of slowness in the system?  That wasn't always the case, I wonder what
has changed since the Plone 2.1 days of Plone.org to make it so much
more painful.  Beyond performance issues and automatic emails, is
there any real difference in the commenting/voting process between the
two?

> Now I do agree that what we have seen in terms of submitted "plip's"
> in the last days is for the most part nothing that deserves this name.
> however I don't see a software problem, but a problem in an undefined
> or not-followed process here. What we have seen is for the most part
> feature wishes, which at some points have been raised for the first
> time in any community discussion.
>
> The PLIP process used to be:
>
> - If you have an idea, you discuss it on the plone-dev mailing list

This has only rarely been the case.  Often, PLIPs were written before
feedback was solicited.

> - After the community has provided feedback and you got som

Re: [Framework-Team] PLIPs in Trac

[Hanno Schlichting]

On Fri, Jun 19, 2009 at 2:03 AM, Maurits van Rees wrote:
> I do not really mind either way.  But I talked with Jean-Paul Ladage
> about this today and he is right in saying that end users wanting to
> know the future of Plone will look at the roadmap on plone.org and
> they will not be impressed: http://plone.org/products/plone/roadmap

The old roadmap is obviously supposed to be replaced by the Trac one
from http://dev.plone.org/plone/roadmap. This was supposed to happen
shortly after 3.3 is released.

Hanno

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIPs in Trac

[Maurits van Rees]

On Thu, Jun 18, 2009 at 11:48:24PM +0100, Matthew Wilkes wrote:
> Hi all,
>
> I'd like to open a public discussion on where tracs should be.  As some 
> of you may know, I'm very much against the PLIPs-in-trac system that has 
> been implemented following out-of-band discussions last year.
>
> I think we need to make a proper decision, I'm not sure how that will  
> happen, but if it'll stop me whinging either way.
>
> For Plone <4.0 we've put PLIPs on plone.org, this has the following  
> advatanges:
> - Unique, relatively low number for each PLIP
> - Custom content type enforces PLIP structure
> - Workflow matches our process

I do not really mind either way.  But I talked with Jean-Paul Ladage
about this today and he is right in saying that end users wanting to
know the future of Plone will look at the roadmap on plone.org and
they will not be impressed: http://plone.org/products/plone/roadmap

They will see a bunch of plips for 3.3, one for trunk, and then about
40 'Proposals being discussed'.  Since some are apparently being
discussed since 2005 these 40 proposals might as well be ignored as
there is no guarantee or indication about when they might get
included.  This is not the sign of the healthy, active project that
Plone still is.


> The disadvantage of it being on a different site has been raised, but I 
> don't buy this.  How often do you want to look at the bugs and PLIPs for 
> a release at the same time?  They have a completely different process.
>
> The current crop of PLIPs for 4.0 are very unstructured, only the ones  
> copied verbatim from plone.org have seconders.  We're having to bodge  
> workflow by assigning different milestones.  It's really suboptimal.
>
> Do others agree with me, or do you prefer trac?
>
> Despairingly yours,
>
> Matt
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"Yes, we study economics,
got to make the money make some kind of sense."  - Geoff Mann

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIPs in Trac

[Hanno Schlichting]

Hi.

Where and how to manage PLIP's is both a matter of a defined process
and some software supporting this process.

One of the main driving reasons to move all Plone Core development
related information into Trac, was to have one place to manage and get
an overview of all relevant information. If we need to get an overview
of where Plone 3.3 currently is, we can only answer this based on the
status of certain tasks and bugs in Trac plus the information shown on
the plone.org/products/plone page. If you need to later find out what
small feature / plip or bug has been part of which release, it is
easier if all this information is in one place.

Now when it comes down to the exact software features of Trac vs. a
Plone content type, they are pretty much the same from what I can see:

- Notion of ownership of the plip by a user
- Assignment to a milestone / release
- Unique ID
- Short title
- Full text description
- Workflow state
- Comments

What is different about these two:

- PSC has multiple text fields for various sub-headings, whereas Trac
only has one text field and the structure needs to be defined by a
template. The structure given by PSC has often been ignored, as
there's too many fields with unclear separation.
- PLIP's in PSC can only be edited by members of the plone core
development team, whereas tickets in Trac can be worked on by anyone
with collective write access.
- There's a more sophisticated specialized workflow in PSC for PLIP's
that doesn't match the reality. Usually I used to move things into the
appropriate stages all the time, but the workflow was largely unused
in practice. Since we upgraded to Trac 0.11, we can define a
specialized workflow in Trac as well, that could actually match our
process.
- Trac has the ability to let users subscribe to tickets via the CC,
so you can get updates about the progress of a particular ticket.

Following this I don't see a clear win on the technical side for PSC,
but see Trac as more feature-rich and tailored to this particular
need. Another reason to move things out of Plone, has been the
particular slowness of plone.org. Commenting on PLIP's to cast votes
has been an utter pain in the past.

Now I do agree that what we have seen in terms of submitted "plip's"
in the last days is for the most part nothing that deserves this name.
however I don't see a software problem, but a problem in an undefined
or not-followed process here. What we have seen is for the most part
feature wishes, which at some points have been raised for the first
time in any community discussion.

The PLIP process used to be:

- If you have an idea, you discuss it on the plone-dev mailing list
- After the community has provided feedback and you got some positive
feedback, you proceed to write down a more detailed description of the
problem and the exact way you want to technically solve it
- You put this detailed text in as a PLIP into the designated spot
(which used to be PSC)
- The framework team sets a deadline on when they will evaluate the
PLIP's targeted for a specific release and the last date they accept
new contributions for evaluation
- ... and so on with a first feedback round on the general idea,
opportunities for polishing by the PLIP author and some more process
around actually doing the technical work and reviewing it

What has been missing for most recent tickets, is the entire community
discussion and feedback step. What has also been missing is a clearly
defined description of this process and a template to use for a PLIP
and a list of points that need to be addressed in it, to make
something a valid PLIP.

I think blaming a software for any of these last points isn't helpful.
Restricting the ability to add PLIP's to a smaller group in PSC has
helped to minimize some of the effects, but it's not a good solution
to restrict contribution in that way.

Hanno

On Fri, Jun 19, 2009 at 12:48 AM, Matthew
Wilkes wrote:
> For Plone <4.0 we've put PLIPs on plone.org, this has the following
> advatanges:
> - Unique, relatively low number for each PLIP
> - Custom content type enforces PLIP structure
> - Workflow matches our process
>
> The disadvantage of it being on a different site has been raised, but I
> don't buy this.  How often do you want to look at the bugs and PLIPs for a
> release at the same time?  They have a completely different process.
>
> The current crop of PLIPs for 4.0 are very unstructured, only the ones
> copied verbatim from plone.org have seconders.  We're having to bodge
> workflow by assigning different milestones.  It's really suboptimal.

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIPs in Trac

[Ricardo Alves]

Alec Mitchell wrote:

I'm in agreement that the plone.org system is preferable; however I
think it's probably a little late to change this.  It does seem like
the "PLIPs" submitted so far are mostly unstructured feature requests.
 Even the better ones are pretty minimal.



I think the same, most of the PLIPs look like feature requests, and I'm 
not sure if everyone who submitted a PLIP is aware that it means they 
should be responsible for implementing/championing it...


With PLIPs at plone.org there was also the permission "barrier": only 
people in the core developer team could submit PLIPs.


Ricardo



On Thu, Jun 18, 2009 at 3:48 PM, Matthew
Wilkes wrote:

Hi all,

I'd like to open a public discussion on where tracs should be.  As some of
you may know, I'm very much against the PLIPs-in-trac system that has been
implemented following out-of-band discussions last year.

I think we need to make a proper decision, I'm not sure how that will
happen, but if it'll stop me whinging either way.

For Plone <4.0 we've put PLIPs on plone.org, this has the following
advatanges:
- Unique, relatively low number for each PLIP
- Custom content type enforces PLIP structure
- Workflow matches our process

The disadvantage of it being on a different site has been raised, but I
don't buy this.  How often do you want to look at the bugs and PLIPs for a
release at the same time?  They have a completely different process.

The current crop of PLIPs for 4.0 are very unstructured, only the ones
copied verbatim from plone.org have seconders.  We're having to bodge
workflow by assigning different milestones.  It's really suboptimal.

Do others agree with me, or do you prefer trac?

Despairingly yours,

Matt

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


--
Ricardo Alves 
Eurotux  



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIPs in Trac

[Alec Mitchell]

I'm in agreement that the plone.org system is preferable; however I
think it's probably a little late to change this.  It does seem like
the "PLIPs" submitted so far are mostly unstructured feature requests.
 Even the better ones are pretty minimal.

Alec

On Thu, Jun 18, 2009 at 3:48 PM, Matthew
Wilkes wrote:
> Hi all,
>
> I'd like to open a public discussion on where tracs should be.  As some of
> you may know, I'm very much against the PLIPs-in-trac system that has been
> implemented following out-of-band discussions last year.
>
> I think we need to make a proper decision, I'm not sure how that will
> happen, but if it'll stop me whinging either way.
>
> For Plone <4.0 we've put PLIPs on plone.org, this has the following
> advatanges:
> - Unique, relatively low number for each PLIP
> - Custom content type enforces PLIP structure
> - Workflow matches our process
>
> The disadvantage of it being on a different site has been raised, but I
> don't buy this.  How often do you want to look at the bugs and PLIPs for a
> release at the same time?  They have a completely different process.
>
> The current crop of PLIPs for 4.0 are very unstructured, only the ones
> copied verbatim from plone.org have seconders.  We're having to bodge
> workflow by assigning different milestones.  It's really suboptimal.
>
> Do others agree with me, or do you prefer trac?
>
> Despairingly yours,
>
> Matt
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] PLIPs in Trac

[Matthew Wilkes]

Hi all,

I'd like to open a public discussion on where tracs should be.  As  
some of you may know, I'm very much against the PLIPs-in-trac system  
that has been implemented following out-of-band discussions last year.


I think we need to make a proper decision, I'm not sure how that will  
happen, but if it'll stop me whinging either way.


For Plone <4.0 we've put PLIPs on plone.org, this has the following  
advatanges:

- Unique, relatively low number for each PLIP
- Custom content type enforces PLIP structure
- Workflow matches our process

The disadvantage of it being on a different site has been raised, but  
I don't buy this.  How often do you want to look at the bugs and PLIPs  
for a release at the same time?  They have a completely different  
process.


The current crop of PLIPs for 4.0 are very unstructured, only the ones  
copied verbatim from plone.org have seconders.  We're having to bodge  
workflow by assigning different milestones.  It's really suboptimal.


Do others agree with me, or do you prefer trac?

Despairingly yours,

Matt

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team