Mark's point that we need to ensure that the quality of the content is high is a very good one which I agree with completely. At the same time, we're going to take heat if there is a lot of extraneous material, which I guess is a quality issue.
If there is a possibility to move material into a separate plug-in then we should consider it. Perhaps the visual modeling material? Refactoring out some plug ins would have a few advantages: 1. It would slim down the base process, which I still think is a good thing. 2. It provides some examples of plug-ins, which would also be good. We've been talking a lot about the opportunity for plug-ins, but not a lot has emerged yet. Granted, there is a lot of good work going on with plug-ins which should soon bear fruit. Speaking of which, the ADT plug-in will soon be available for review. - Scott On Fri, December 1, 2006 6:51 am, Chris Armstrong said: > I completely agree with Mark's perspective. We shouldn't be as concerned > about size, but more about essential content. To Scott's point, it might > not > be a bad idea to consider refactoring content into multiple plugins, so > for > those organizations and teams that are concerned about size can control it > (but we should probably get some feedback from the user community before > we > dive into it). One thing about Jim's page count to consider is that method > content is re-published in the various descriptors used in the capability > patterns and delivery process. This might artificially inflate the > "actual" > size of original content... > > Thanks, Chris ~:| > > _____ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Friday, December 01, 2006 4:14 AM > To: Eclipse Process Framework Project Developers List > Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic > > > I think we should worry less about the number of pages and more about the > value of the content on each page. > > The number of pages will be artificially bloated by the page layout > delivered by Composer. For example the Architecture work product covers > two > pages of printed paper but only delivers about half a page of text in a > 12pt > font. > > On a more general point, I am uncomfortable about the way recent > discussions > have focused on the size of the process, as if somehow smaller means more > agile. I do not believe that agility is a function of the size of the > process. It is a function of how people behave, not what the process does > or > does not explicitly document. > > I believe that it is important that OpenUP/Basic delivers value to it's > users. I do not think that the primary audience for OpenUP/Basic is going > to > be projects made up of small teams of battle-hardened agile development > veterans. Projects like that don't really need to refer to *any* written > process. > > So who's our audience? Small teams of less experienced developers adopting > new technologies and techniques? People who want to use the Unified > Process > but want a free alternative to RUP? I think so. If that is the case then > OpenUP/Basic had better be delivering some real content - by which I means > actual practices and guidance to help them reach a point where they don't > need it anymore. > > That stuff consumes pages. And (if done right) delivers value. > > When deciding what to chop out of OpenUP/Basic, we need to make sure that > we > ask the question "does this content deliver value to our audience?" If the > answer is yes and we are still at 542 pages, then I am ok with that. > > Cheers > > Mark > > > Mark Dickson > Principal Solution Architect > SAE Practice > m 0780 1917480 > w www.xansa.com <https://extranet.xansa.com/,DanaInfo=www.xansa.com+> > e [EMAIL PROTECTED] > > > [EMAIL PROTECTED] wrote: ----- > > > > To: "Eclipse Process Framework Project Developers List" > <[email protected]> > From: "Scott W. Ambler" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > Date: 12/01/2006 03:49AM > Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic > > Seems to me that we need to cut it down dramatically. > > What material can we move out into separate plug-ins? > > - Scott > On Thu, November 30, 2006 7:56 pm, Jim Ruehlin said: >> The best estimate I have so far of the size of OpenUP/Basic is 542 pages >> (8 ½ x 11). This is based on what?s in CVS as of 11/29/06. This should >> give us an initial benchmark for our OpenUP/Basic 1.0 scoping efforts. >> >> >> >> I determined the size by creating a PDF of the entire website, doing a >> breadth-first walk along the links starting with the Intro page. I didn? >> t see anything missing, but I only made a cursory examination of the PDF >> file. Glossary terms, templates, and examples are included in the page >> count. Also, many web pages are longer than 8 ½ x 11, so this estimate >> is based on a book layout, not a website layout. >> >> >> >> - Jim >> >> >> >> ____________________ >> >> Jim Ruehlin, IBM Rational >> >> RUP Content Developer >> >> Eclipse Process Framework (EPF) Committer www.eclipse.org/epf >> >> email: [EMAIL PROTECTED] >> >> phone: 760.505.3232 >> >> fax: 949.369.0720 >> >> >> _______________________________________________ >> epf-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/epf-dev > <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or > g,SSL+> >> > > > Practice Leader Agile Development, IBM Rational > http://www-306.ibm.com/software/rational/bios/ambler.html > <https://extranet.xansa.com/software/rational/bios/ambler.html,DanaInfo=www- > 306.ibm.com+> > > Refactoring Databases ( > http://www.ambysoft.com/books/refactoringDatabases.html > <https://extranet.xansa.com/books/refactoringDatabases.html,DanaInfo=www.amb > ysoft.com+> ) is now > available. > > _______________________________________________ > epf-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/epf-dev > <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or > g,SSL+> > > > > > Whilst this email has been checked for all known viruses, recipients > should > undertake their own virus checking as Xansa will not accept any liability > whatsoever. > > This email and any files transmitted with it are confidential and > protected > by client privilege. It is solely for the use of the intended recipient. > Please delete it and notify the sender if you have received it in > error. Unauthorised use is prohibited. > > Any opinions expressed in this email are those of the individual and not > necessarily the organisation. > Xansa, Registered Office: 420 Thames Valley Park Drive, > Thames Valley Park, Reading, RG6 1PU, UK. > Registered in England No.1000954. > t +44 (0)8702 416181 > w www.xansa.com > > _______________________________________________ > epf-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/epf-dev > Practice Leader Agile Development, IBM Rational http://www-306.ibm.com/software/rational/bios/ambler.html Refactoring Databases ( http://www.ambysoft.com/books/refactoringDatabases.html ) is now available. _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
