[pypy-svn] r26739 - pypy/extradoc/talk/agile2006

[bea at codespeak.net]

Author: bea
Date: Wed May  3 23:07:36 2006
New Revision: 26739

Modified:
   pypy/extradoc/talk/agile2006/draftpaper_agile2006.txt
Log:
tuning, tuning and more tuning - please review....

Modified: pypy/extradoc/talk/agile2006/draftpaper_agile2006.txt
==============================================================================
--- pypy/extradoc/talk/agile2006/draftpaper_agile2006.txt	(original)
+++ pypy/extradoc/talk/agile2006/draftpaper_agile2006.txt	Wed May  3 23:07:36 2006
@@ -10,7 +10,7 @@
 PyPy is an Open Source project, partly funded by the European Union, employing
 agile techniques evolved within the Python Community such as "sprint-driven
 development".The project started as a grass-root F/OSS effort in late 2002 and
-recieved EU-funding from December 2004 until November 2006.  In this paper we
+received EU-funding from December 2004 until November 2006.  In this paper we
 will present the various influencing factors that creates the hybrid project
 process that is PyPy. These influencing factors are the F/OSS Python Community
 (climate of the community from which PyPy grew from), agile practices (such as
@@ -19,7 +19,7 @@
 influencing factors laid the foundation for the custom-made project process
 that makes this unique hybrid project work and the main factor for driving this
 process is the skills of the team of core developers instigating the project.
-PyPy, with it´s open and transparent communication and collaborative workstyle,
+PyPy, with its open and transparent communication and collaborative work style,
 is again a proof that the best agile practice is the people factor.
 
 .. raw:: latex
@@ -32,8 +32,8 @@
 =============
 
 This paper presents the story and the experiences gathered so far in the PyPy
-project concerning how to integrate such diverse perspectives as agile
-practices being used in a distributed and dispersed development style in an
+project. The challenge has been to integrate such diverse perspectives as agile
+practices being used in a distributed development style in an
 Open Source project that is partly funded by the European Union.
 
 The PyPy project started as a grass-root effort among core developers in the
@@ -42,7 +42,7 @@
 driven from a non-profit perspective which rapidly increased in complexity when
 the Open Source project applied for EU-funding.  
 
-Today the project have over 4 years of intense activity as a Open Source
+Today the project has over 4 years of intense activity as an Open Source
 community (F/OSS) effort and have completed a successful first year of the
 EU-funded effort.  In order to understand how the PyPy project managed and
 manages to strike a balance between being an F/OSS community, while also having
@@ -53,9 +53,9 @@
 The influencing factors of the PyPy project process are:
 
 - The F/OSS/Python community factor. Different Open Source communities have
-  different "flavours" regarding culture, communication climate, structure,
+  different "flavors" regarding culture, communication climate, structure,
   decision-process etc. PyPy was born out of the Python Community and share
-  some of it´s characteristics which have had a huge influence on the project
+  some of its characteristics which have had a huge influence on the project
   process so far. Aspects such as distributed/dispersed development and the
   supporting practices and infrastructure in place to quality assure software
   development in a collaborated manner are part of this important influencing
@@ -73,14 +73,14 @@
   Driven Development and explain how these are implemented in PyPy.
 
 - The EU factor. PyPy is the first F/OSS community that organized themselves
-  into an EU-project, recieving EU-funding. It has had a huge impact on the
+  into an EU-project, receiving EU-funding. It has had a huge impact on the
   project, and it is important to identify how EU project and process
   requirements can be "weaved" into an Agile F/OSS project - a challenge
-  indeed. The EU-funding has been and still is an enourmous opportunity, the
+  indeed. The EU-funding has been and still is an enormous opportunity, the
   project would not have had the rapid progress and impact it is now having
   without the funding. It is also very important to note that without striking
   the right balance between the three main influencing factors (F/OSS, agile
-  and EU-funding) this factor might also prove to be a "showstopper", something
+  and EU-funding) this factor might also prove to be a "show stopper", something
   that might influence the PyPy community negatively. This is a constant
   challenge - we explain here how we created our process and added a
   "consortium-level" structure to the F/OSS community and the steps we took in
@@ -88,7 +88,7 @@
 
 Our conclusion so far in the project is that we believe that the practice of
 "sprinting", as being used in the PyPy project, makes Agile and
-Distributed/dispersed workstyles more possible to combine. We also believe it
+ Distributed/dispersed work styles more possible to combine. We also believe it
 is a very useful practice for creating value and ensuring quality in a projects
 with hybrid cultures and methodologies. It is our aim to start to show-case
 this with experiences from the first funded year of PyPy. We also feel that our
@@ -126,7 +126,7 @@
 optimized compiler and interpreter purely in Python, applying Aspect Oriented
 Programming and abstract interpretation techniques.  The methodology objective
 aims at showcasing the "sprint-driven development method" being used by PyPy
-and you can view this paper as part of fullfilling the methodology objective.
+and you can view this paper as part of fulfilling the methodology objective.
 
 Strategy:
 +++++++++
@@ -150,8 +150,8 @@
 
 It is difficult to estimate the amount of people involved in PyPy but we
 estimate that ca 300-500 people "follow actively" the progress of the project -
-this might mean reading emails, IRC logs and documention in some cases, asking
-questions and sending bug reports in other cases.There are ca 50 people that
+this might mean reading emails, IRC logs and documentation in some cases, asking
+questions and sending bug reports in other cases. There are ca 50 people that
 have commit-rights to the source code. The core group of developers consists of
 ca 10 people. 
 
@@ -166,14 +166,14 @@
 work-packages and in total 58 deliverables which are high-level functional and
 non-functional requirements that were formulated in a proposal and form the
 "Description of Work" in the contract with the European Commission. The funding
-recieved for this effort is 1.3 million euros. Of the core group of developers
+received for this effort is 1.3 million euro. Of the core group of developers
 mentioned above almost all of them (ca 10 people) are involved in some sense in
 the partner companies and organizations of the PyPy consortium.
 
 History:
 ++++++++
 
-The ideas behind PyPy started via discussions on european mailing-lists in the
+The ideas behind PyPy started via discussions on European mailing-lists in the
 Python community late 2002 by people that had been active in the Python
 community for some time, core developers interested in language implementation.
 They based the discussions and ideas partly on their experiences with
@@ -234,14 +234,14 @@
 previous successful Python projects and this prior community experience was
 vital for the evolving of the PyPy community due to the established trust in
 expert skills of the core developers starting PyPy - again the people
-factor.Thus making it easier recruit people into the PyPy community.
+factor. Thus making it easier recruit people into the PyPy community.
 
 The PyPy project inherited the focus on collaborative approaches and open
 communication climate.  The nature of using sprints as a core technique as a
 way to kick-start the project as well as moving the sprints to different
 locations as a strategy to encourage participation by meeting people locally
 are clear examples of this. During the period of 2003-2004 6 sprints were
-arranged in various european cities, hosted by universities and private
+arranged in various European cities, hosted by universities and private
 persons, participation funded privately. The effect on the evolving community
 was a stable subscriber participation on the development list of between
 140-150 people. After the EU-funding and the more systematic structure of
@@ -274,11 +274,11 @@
 
 The main communication channels between developers involved in PyPy is to
 discuss over IRC (Internet-Relay-Chat) - open for all that are interested.
-Several mailinglists for discussions and information is also used. Webpages,
+Several mailing lists for discussions and information is also used. Web pages,
 documentation, tutorials, talks and papers etc are all available on the central
-developer server for everyone.A very useful feature that really supports
+developer server for everyone to access. A very useful feature that really supports
 information and communication (the author can attest to this from her own
-experience) are the public email archives covering the key mailinglists - going
+experience) are the public email archives covering the key mailing lists - going
 back to the start of 2003.
 
 An extensive coding guide, published on codespeak.net (development website)
@@ -287,9 +287,9 @@
 test and documentation guidelines.
 
 Now - all this infrastructure is being used in almost all larger open source
-projects and quite a few of them are much more hierarchial and non-transparent
-in their communication.  In PyPy there is no hierarchy for recieving
-commit-rights. A newcomer to PyPy can instantly recieve an account on the
+projects and quite a few of them are much more hierarchical and non-transparent
+in their communication.  In PyPy there is no hierarchy for receiving
+commit-rights. A newcomer to PyPy can instantly receive an account on the
 development server, with full commit rights to the version control system. The
 reason why there are no constraints is that the process is very much
 self-organized and managed by the developers from a social level (peer review,
@@ -297,7 +297,7 @@
 strong automated tools covering tests, versions and back ups covering the
 technical level.
 
-In a distributed and dispersed workstyle these two (social and technical)
+In a distributed and dispersed work style these two (social and technical)
 levels needs to be consistent and support each other, discrepancies would be
 immediately noticed. As stated before - the people factor is again evident and
 in order to encourage participation and contribution there has to be trust as
@@ -316,15 +316,15 @@
 Sync-meetings are weekly short coordination meetings between developers, open
 to all developers active in the PyPy community, usually but not necessarily
 involving aspects of EU-funded work on deliverables.  These 30 minute
-IRC-meetings serve a weekly synchronisation for regular discussions and
+IRC-meetings serve a weekly synchronization for regular discussions and
 integration of ongoing work.  Meetings are prepared with an agenda sent out to
 pypy-dev and minutes are distributed on pypy-dev and archived in the repository
-with publicly accessible links.Preparing, managing and documenting the meetings
+with publicly accessible links. Preparing, managing and documenting the meetings
 is rotated between active developers and is self-organized as well.
 
-Sync-meetings have proven to be a very good complement to a process in which
+Sync-meetings have proved to be a very good complement to a process in which
 the project sprints every 6th week. Sync-meetings keep cohesion as well as a
-team focus-and-feel for the dispersed workstyle between sprints. 
+team focus-and-feel for the dispersed work style between sprints. 
     
 Influencing factors: agile practices in PyPy
 ============================================
@@ -349,7 +349,7 @@
 community (framework-centric, distributed, no "business user" present), some of
 the XP mantras /practices couldn't be done directly.  We decided to try to do
 "as much XP as possible" for short, highly-focused sessions, with all active
-committers colocated."
+committers collocated."
 
 The Zope community as well as other Python projects such as PyPy have seen that
 sprints have goals beyond the creation of software:
@@ -358,7 +358,7 @@
   with the core developers.
 
 - It is a live training session not only in producing code but also in the
-  development methods being used (TDD, pairprogramming etc, the sprint method
+  development methods being used (TDD, pair programming etc, the sprint method
   in itself).
 
 - It supports activities such as design decisions and high-level requirements
@@ -384,7 +384,7 @@
 sprint driven development.
 
 The sprint method, as well as key aspects of F/OSS supportive infrastructure
-and practices was established within the project before PyPy recieved it´s
+and practices was established within the project before PyPy received it´s
 EU-funding.  Thus, in the proposal,we put much emphasis on the methodology in
 itself when designing the consortium level process. Examples of how this was
 done was that we created a methodology objective, specific deliverables
@@ -401,11 +401,11 @@
 
 Why did PyPy choose sprinting as a key technique?  It is a method that fits
 distributed teams well because it gets the team focused around visible
-challenging goals while working collarobatively (pair-programming, status
+challenging goals while working collaboratively (pair-programming, status
 meetings, discussions etc) as well as accelerated (short increments and tasks,
 "doing" and testing instead of long startups of planning and requirement
 gathering, continuous integration). This means that most of the time a sprint
-is a great way of getting results and getting new people aquainted - a good
+is a great way of getting results and getting new people acquainted - a good
 method for dissemination of knowledge and learning within the team. 
 
 A key insight, worthwhile for other EU-projects to ponder, is how an agile
@@ -426,11 +426,11 @@
 
 - a consortium of partners performing the work described in the contract
 
-- a project co-ordinator managing contract administration and communication
+- a project co-coordinator managing contract administration and communication
   between consortium and the Commission
 
 - a project manager, responsible for the project reaching it´s goals within the
-  timeframe and budget
+  time frame and budget
 
 The challenge was to design a project process that created a minimal amount of
 changes to the structure being in use in the F/OSS project. It was especially
@@ -440,7 +440,7 @@
 the project.
 
 We identified a minimalistic approach of management roles (project
-co-ordinator, project manager, assistant project manager) and created a
+co-coordinator, project manager, assistant project manager) and created a
 management team to make sure that there was collaboration between these roles.
 Although the responsibility rested on the different management roles and the
 management team the strategy implemented was to delegate as much as possible of
@@ -460,10 +460,10 @@
 play.
 
 Sprints were budgeted for and designed into the process, together with a
-timeplan for all deliverables. The project was divided into three different
-phases, depending on the nature of the workflow. In that sense you could
+time plan for all deliverables. The project was divided into three different
+phases, depending on the nature of the work flow. In that sense you could
 describe the EU-part of the project as a fixed-contract style of work, but with
-timeplan, deliverables and work package descriptions on a high-level, not
+time plan, deliverables and work package descriptions on a high-level, not
 broken down into more granular tasks.
 
 Resource tracking and reporting
@@ -471,24 +471,24 @@
 
 The nature of reporting on a consortium level is very much focused on the costs
 incurred by each partner compared to budget, by the consortium on a specific
-workpackage and of the consortium overall. The consortium is free to reallocate
-budgeted manmonth funding between partners during the project. The project
+work package and of the consortium overall. The consortium is free to reallocate
+budgeted man month funding between partners during the project. The project
 reports costs per period - PyPy have two periods.
 
 Again - the need for open and transparent communication together with a
 collaborative climate created the need to have what we believe a unique view on
-cost reporting within the project. In PyPy all timesheets are gathered on a
+cost reporting within the project. In PyPy all time sheets are gathered on a
 monthly basis and stored in central repository, accessible for all consortium
 partners (managers and developers alike).  Cost claims from all partners are
 gathered on a six month basis. This data helps the management board and
 technical board to assess the status of work.
 
-Templates for timesheets, costs claims, resource tracking tools etc are created
+Templates for time sheets, costs claims, resource tracking tools etc are created
 in open formats and all data is stored under the same version control that we
 use for the source code. All reports are produced with docutils/ReST format
-which together with automated mailinglists for covering updates in the version
+which together with automated mailing lists for covering updates in the version
 control repositories allows for collaborate peer-reviewing regarding the
-EU-level of reports. Again the strategy was to use the same tools and practises
+EU-level of reports. Again the strategy was to use the same tools and practices
 on consortium level work as is used in the development process.  Interesting to
 note is that the technical reports written for the Commission regarding certain
 deliverables and progress have also been a great help towards the community who
@@ -507,13 +507,13 @@
 
 The communication infrastructure being used on the consortium level of work
 mirrors that of the development work - having years of experience on the
-distributed workstyle. In the case of PyPY there are mailinglists as well as
+distributed work style. In the case of PyPY there are mailing lists as well as
 IRC channels for consortium level work. We even implemented a procedure in our
 internal consortium agreement to allow for virtual meetings for decisions in
 the consortium. So far this have been the primary meeting form and it has
 worked well as a channel for making decisions. IRC-logs and minutes support the
 procedure. In some cases decisions have also been made via email on the
-consortium mailinglist.
+consortium mailing list.
 
 Although not the primary focus it is also useful to have the regular sprints to
 coordinate specific issues between some partners or between all partners, have
@@ -521,7 +521,7 @@
 board etc.
 
 Our funding have also resulted in the possibility to have a more unorthodox
-documention - the project have experimented in filming sprints to show the
+documentation - the project have experimented in filming sprints to show the
 development method as well as filming talks and discussion. Our film material
 is planned to be released before summer 2006.
 
@@ -531,7 +531,7 @@
 Developer driven versus formal project structure
 ------------------------------------------------
 
-The fear of a top-down, hierarchial decision process of the consortium was a
+The fear of a top-down, hierarchical decision process of the consortium was a
 justified one.  It is interesting for us to note that now, having the
 experience and more contractual overview to note that there is nothing in the
 requirements from the Commission that forces a project to a more traditional
@@ -542,7 +542,7 @@
 as consortium work.
 
 The majority of the partners on key roles in the consortium organization had
-been working together since before the funding, procedures and best practises
+been working together since before the funding, procedures and best practices
 had been tried out. The results from the first year showed that a minimalistic
 path could be identified and that the important work would be to review and
 adjust the process when it did not support the work any more, or new situations
@@ -555,7 +555,7 @@
 Agile strategies versus formal EU-contractual requirements
 ----------------------------------------------------------
 
-Our main agile practise, sprint-driven development, was successfully integrated
+Our main agile practice, sprint-driven development, was successfully integrated
 into the formal contractual requirements, allowing for the same free-floating
 agile process of self organizing and decision making as existed before the
 funding, but with a more systematic and documented style.
@@ -566,7 +566,7 @@
 "open-door" policy that allowed us to fund non-consortium persons from the
 community to attend sprints. The budget was allocated, the procedure within the
 sprint context of handling more newcomers were known to us - the main
-showstopper was that PyPy sprint funding did not fit within the customs and
+show stopper was that PyPy sprint funding did not fit within the customs and
 practices of contracts for cost claims in the Commission.
 
 Every time we want to encourage participation and fund people to participate in
@@ -603,7 +603,7 @@
 is progressing much more rapidly in PyPy than more normal F/OSS projects. The
 speed and the dramatically increasing learning curve could make members more
 passive because they do not have the time to follow full-time IRC discussions,
-postings on mailinglists and the actual source code and increasing test suites. 
+postings on mailing lists and the actual source code and increasing test suites. 
 
 This is a challenge and it is the focus of the developer group to try to
 distill and package information in order to help people to better navigate the
@@ -620,7 +620,7 @@
 We believe so. The one clear dominating factor to make all this succeed is, as
 always, the people factor, the CRACK performers as Boehm and Turner calls them
 ("Collaborative, Representative, Authorized, Committed, Knowledgeable").
-. 
+
 
 The core developers of the PyPy project had the right mix of various skills in
 order to succeed in setting up a hybrid environment - enabling them to work
@@ -650,9 +650,8 @@
   
 Drawing from these different skills within the community of developers in the
 PyPy project one possible conclusion would be that a truly agile approach
-dominating the workstyle of an Open Source project will increase the ability of
+dominating the work style of an Open Source project will increase the ability of
 the community to spread the strategy of agility to other domains such as
 entrepreneurship and business models (whether this is done by separate
 individuals, subgroups or the whole group). By doing this hybrid projects such
 as PyPy and others (Zope Europe among others) are made possible.
-