Re: [Framework-Team] Re: PLIP lifecycle
On Dec 28, 2008, at 5:23 , Tom Lazar wrote: i particularly like the notion of using workflow states as 'reminders' to make sure aspects aren't missed. OTOH, workflow states are serial, and it'd be a shame to force teams to do their evaluations in a specific order. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP lifecycle
On Jan 2, 2009, at 14:33 , Tres Seaver wrote: OTOH, workflow states are serial, and it'd be a shame to force teams to do their evaluations in a specific order. You can actually have multiple workflows for a given type. I may be the only person who has ever actually used the feature, but it is truly helpful at times. Having the doc team work in one (simple) workflow, the UI team in another, and the FWT in the main workflow, with gates based on the other two, might be the best solution. Hey, shiny! Thanks for the enlightenment. I could get behind that, if it doesn't end up being too constricting. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP lifecycle
On 27.12.2008, at 23:28, Alexander Limi wrote: On Sat, 27 Dec 2008 09:56:23 -0800, Ross Patterson m...@rpatterson.net wrote: One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. This sounds like a good starting point. +1. +1 i particularly like the notion of using workflow states as 'reminders' to make sure aspects aren't missed. cheers, tom -- Alexander Limi · http://limi.net ___ 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] Re: PLIP lifecycle
Hanno Schlichting hanno...@hannosch.eu writes: The exact way to involve the UI and documentation team needs to be defined. I think we should write up the process first and then sent it for comments to the two others team. We can incorporate their feedback in terms of when and how they like to be involved. It seems like it's important that this part be both structural and lightweight. By structural I mean there should be more than just a we should think about docs when discussing the PLIP gesture. We could define this either through procedure alone or through the tools. Could we include reviews by the other teams in the Trac workflow for PLIPs? That would remove any requirement that someone on the FwT *remember* to check for the external team reviews. :) One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP lifecycle
On Sat, 27 Dec 2008 09:56:23 -0800, Ross Patterson m...@rpatterson.net wrote: One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. This sounds like a good starting point. +1. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
