[pypy-svn] rev 1676 - pypy/trunk/doc/funding
arigo at codespeak.net
arigo at codespeak.net
Fri Oct 10 18:01:13 CEST 2003
Author: arigo
Date: Fri Oct 10 18:01:12 2003
New Revision: 1676
Removed:
pypy/trunk/doc/funding/B5.0_manage_bea.asc
pypy/trunk/doc/funding/B5.1_project_manager.txt
pypy/trunk/doc/funding/B5.4_meetings.txt
pypy/trunk/doc/funding/B5.5_quality.txt
pypy/trunk/doc/funding/B5.6_communication.txt
pypy/trunk/doc/funding/B5.8_ip.txt
Modified:
pypy/trunk/doc/funding/B5.0_manage_bea.txt
pypy/trunk/doc/funding/B5.2_management_structure.txt
Log:
B5 cleanup
Deleted: /pypy/trunk/doc/funding/B5.0_manage_bea.asc
==============================================================================
--- /pypy/trunk/doc/funding/B5.0_manage_bea.asc Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,402 +0,0 @@
-:DELETE:BEGIN
-
- B 5.0 Project Management
-
-:DELETE:END
-
-Project Management
-======================
-
-PyPy as a project will be implementing an agile development
-lifecycle.This choice of development method will have effects on the
-way the project will be structured and managed.
-
-The project will have a structured project plan as is showed in this proposal (workpackages,
-Gantt-chart, deliverables, quality control etc). It also means that the project process, once the
-project get started, will work from a evaluate-feedback-change perspective, or so called
-"learning loops" in which project management will continuosly follow up on the intital
-project plan but also evaluate process, teameffectiveness, communication climate. From these
-learning loops change, when necessary, will be applied throughout the process.
-
-To illustrate the focus on development process as well as project focus:
-
-Stakeholders;
-- EU
-- partners
-- Python communities etc.etc
-
-
-::
-
- Development
- process
-
- Sprint/ Sprint/ Sprint/ Sprint/ Sprint/
- team team team team team
-
- Project process
-
- Stakeholders;
-
- - EU
- - partners
- - Python communities etc.etc
-
-Both the project and the development process are based around critical
-workshops, so called "sprints" that will take place on a six week cycle
-throughout the project (24 months). Around these sprints input and output to
-stakeholders will be structured. The arrows above symbolize the evaluation-
-feedback-change system that will be implemented.
-
-This method will affect the role of the project management, management structure, role of
-coordinator, project meetings, quality control and communication in the project in what we
-have experienced to be a very constructive way.
-
-Our reasons for choosing this development and projectmethod are several:
-
-o This project has a history of 6 months in which the team succesfully implemented sprints
- and agile development methods
-o In this project, teammembers from 5 (?) different countries will work continuosly in separate
- places, sprints will be the main forum in which the teammembers meet up and work
- together in real life
-o The sprints will be open for nonteammembers to participate in the development process, thus
- allowing for an open and feedbackdriven process
-o The sprints will be the forum in which knowledge will be shared and the transparancy within
- the project organisation will be measured
-
-We will during the project focus on evaluating and documenting our projectmethod
-and share knowledge and experience in that area as well. It is our goal that the
-overall deliverables from this project will be a functioning PyPy as well as an
-effective projectmethod for agile development/Open Source projects.
-
-On the following pages we will describe in more detail how this choice of method
-will influence the way this project will be managed.
-
-:DELETE:BEGIN
-
-B 5.1 Project manager
-
-:DELETE:END
-
-Project Manager
-------------------
-
-The PyPy project will have a project management structure that is based upon two
-resources, Jacob Hallén as project manager and Beatrice Düring as assisting
-project manager.
-
-The role of the project manager is to:
-
-o manage the project and its scope of time, budget and deliverables
-o lead the work of the management board and report to the management board
-o execute decisions made in the management board
-o report to the project coordinator
-o support the project coordinator concerning the relations to the EU
-o manage the sprints
-o manage routines for quality assurance of the technical development
-
-The role of the assistant project manager
-
-o report to the project manager
-o participate in reports to management board and project coordinator
-o manage project administration (reports, documentation,etc)
-o manage routines for sprints, quality assurance of project process, resourceallocation
-o manage contact with external partners
-o manage the day-to-day operations of the project (ex. executing decisions made by
-o management board)
-o manage the knowledge process and actively spread information to the Open Source
-o community regarding methods used
-
-The reasons for having a structure based on a project manager and assisting
-project manager are:
-
- both the development and the project process will recieve due attention in that the persons
- chosen have expert skills in these different areas
-
- the project will not be exposed to the risk that a single project manager would mean
- (hhmm dåligt formulera om)
-
- a project of this size with team and stakeholders distributed in several countries needs more
- project management resources
-
-The skills and experience of the combined project management team are as followed:
-
-Large scale projects:
-
-Jacob Hallén have been working since 1994 with large scale development projects. He was a
-consultant for, and later employee of, the LIBRIS Department of the Royal Library of Sweden
-(http://www.libris.kb.se) in the role of Technical Project Manager, with main focus on being
-systems architect for the national bibliography system and interlibrary loan system.
-Participated in international standardisation groups for search systems (Z39.50) and
-interlibrary loans.
-
-He was also the initiator of the international standardisation effort for library services
-information. Participated as the Royal Library representative in ONE-2, an EU funded project
-under the Telematics for Libraries project (http://www.one-2.org)
-
-Since 2000, Jacob have been involved in co-founding AB Strakt (http://www.strakt.com), a
-company developing workflow and document handling systems. There he works in roles as
-developer, project manager, CTO and CEO. The company has grown from 3 employees to
-having 12 full time employees and 6 part time employees so far.
-
-Connected to his work at AB Strakt, Jacob has also been active as co-founder and chairman of
-the Python Business Forum, an international trade organisation for companies that use Python
-as their main tool of business. The PBF has approximately 50 member organisations.
-He is also the project leader for the Europython 2004 conference, to be held in
-Göteborg, Sweden 9-11 June 2004.
-
-Beatrice Düring have experience in large scale education projects involving working with
-consortiums of three companies servicing a stakeholdergroup of about 30 recruiting
-companies. These large education projects was part of a national program to solve shortages
-of skilled IT-personel during the years 1998- 2000. 200 students participated in the projects
-and the projects met their deliverables in that over 80% of the student were employed after the
-education. The project team consisted of 7 persons working full time. As a project manager,
-Beatrice was responsible for meeting project goals, meeting profit margins, leading the team
-and creating strategies for stakeholder participation in the projects. She was also responsible
-for reporting and documenting the project to the client.
-
-Since 2000 she has been involved in similar assigments, one recently finished for University
-of Blekinge in which the education was directed towards recruiting companies in the
-gamedevelopment industry. She has also worked as project manager for several development
-projects during the time 1998-2002.
-
-She has also developed project methods for the companies and teams shes been working with
-and have also been working with quality assurance of development projects. Her current
-company, Change Maker is also working with supporting smaller companies in the
-application process for the EU Framework 3 (Växtkraft Mål 3) and has a experience of
-working with similar EU-funded projects since 1997.
-
-Financial tracking in projects:
-
-Jacob Hallén has a widespread experience of founding and managing companies as well as
-being project manager for large scale projects. This means that
-
-The large scale education projects that Beatrice managed had a profitmargin of 20% which
-was met. The total budget for these projects was 20 million SEK. She has also recently been
-involved in the prestudy, budgeting and start of a 6 year long education project in Arvika,
-Sweden with a total budget of 18 million SEK.
-
-During her time as a manager for the education and consultdepartment in NetGuide
-Scandinavia (1999-2002) she had budget and resultresponsibility.
-
-Leadership skills:
-
-Jacob Hallén have experienced leadership challenges in different situations. Since
-
-Beatrice Düring have experience from leadership situations in projects as well as in
-lineorganisations since 1998. During four years she was a part of a management team of five
-people, leading teams of 5 to 14 people. As a leader, Beatrice was responsible for coaching,
-motivating and developing her personel.
-
-Beatrice employs strategies of empowerment, active listening combined with creating and
-maintaining an open communication climate based on honesty and trust the achieve goals
-together with her team. Beatrice have been teaching management oriented courses
-(leadership, project management, communication, conflictresolving) for Learning Tree
-International since 2003 in both Sweden and USA.
-
-:DELETE:BEGIN
-
-B 5.2 Management structure
-
-B 5.3 Coordinator dont write
-
-B 5.4 Project meetings
-
-:DELETE:END
-
-
-Project Meetings
------------------------
-
-Management Board will meet at the start of the project and two times per year or on an ad hoc
-basis as requested. The meetings will normally be scheduled to rotate between countries of the
-EU and mainly the principal contractors home base. The project manager is responsible for
-the invite and agenda as well as managing the meetings. Objectives on these meeting are
-tracking progress regarding workpackages, budget, timescale and strategies for involving
-
-stakeholders as in partners or new partners. Agenda and discussions/decisions on these
-meeting will be documented and put up in the internal project web.
-
-Team Meetings
-+++++++++++++++++++
-
-The project team will meet at the "sprints" which take place on a six week cycle ( se below).
-During the sprints, there will be time allotted to discuss and evaluate the project process, track
-progress, discuss resource allocation, new teammembers. The project manager is responsible
-for the invite and agenda as well as managing the meetings.Agenda and discussions/decisions
-on these meeting will be documented and put up in the internal project web.
-
-Project review workshops ("learning loops")
-
-Every six months, as preparation for the Management Board meetings and project reviews
-from the EU project office, the project management team invites the team to an evaluation
-workshop, lasting for a day, in which product as well as process is being reviewed.
-Riskassessment is also an important part of this workshop. This meeting could result in
-proposed changes that will then be reported to the Management Board for decision.
-The project manager is responsible for the invite and agenda as well as managing the
-meetings.Agenda and discussions/decisions on these meeting will be documented and put up
-in the internal project web.
-
-
-"Sprint" Meetings are the key to PyPy's technical development
-
-Key to PyPy's technical development and research are so called "sprints". These publically
-announced one-week meetings serve as an intense working forum to rapidly discuss and
-implement key PyPy ideas with agile methodologies. Developers usually pair up and write
-unit-tests to test the to-be-implemented features before actually adding them. The unittest-first
-approach helps to understand the planned feature. Additionally, the discussion in a pair makes
-sure that obviously wrong pathes of development are avoided. If something seems too hard to
-test or to pin down explicitely this is taken as an indication of an underlying design problem.
-
-Note that more traditional approaches usually follow a model where developers work alone
-and only meet to talk. Instead with sprint-driven development talking and actually
-implementing resulting ideas ensures a more focused approach with fast feedback cycles.
-While the free software community is successful especially because of it's open
-communication model sprints are an accelerator to this process. While coding in pairs
-developers educate each other which leads to a broader common understanding of the project.
-During a sprint multiple pairs want to work in parallel which adds pressure on design
-decisions so that independent development of components of the system is possible. Thus
-sprints not only deepen the communication and understanding among researchers and
-developers but they imply a working process which enhances the software design in multiple
-ways. The project manager is responsible for the invite (stated goal) and agenda as well as
-processmanagement during the sprints. Agenda and discussions/decisions on these sprints will
-be documented and put up in the internal project web.
-
-With a very-high-level-language like Python rapid development in coding-sprints becomes
-especially effective. A VHLL-language generally allows to focus on ideas rather than on low-
-level language details. In combintation with pervasive test-driven development this eases
-
-high-quality rapid evolution towards the intendent goals. Obviously, the PyPy developers are
-very experienced with Python and bigger applications in general. Thus the full potential of
-agile methodologies is unvealed during PyPy sprints. In less than five weeks worth of
-development (during four sprints) the group produced a working prototype which is a big
-success not only in the eyes of its developers.
-
-Technical decisions
-+++++++++++++++++++++++++++++
-
-Major design or technical decisions are usually reached through consensus during the sprints.
-If a conflict cannot be resolved there then the technical board gets the final say. The members
-of the technical board are appointed by a vote of everyone who has commit rights to the
-source repository. However, it is expected that design and implementation choices will
-usually be determined by consensual agreement or by informal votes on the development
-mailing list. This is common practice within the Python and many others free softare
-communities. Also, the PyPy developers and researchers will construct few if any formal
-hierarchies between them. Constantly working together with agile methodologies and the
-visilibity of each individual contribution help enforce high-quality program code and good
-design decisions.
-
-:DELETE:BEGIN
-
-B 5.5 Quality control of technical development
-
-:DELETE:END
-
-Quality control of technical development
-----------------------------------------------
-
-The PyPy project will ensure quality by a variety of means. On the grand scale, the
-involvement of excellent researchers ensures that the general direction takes care of latest
-insights in language research. Moreover, we will publish our research results on conferences
-and to scientific and free software communities. This forms the basis to maintain a high-
-quality general technical direction.
-
-The developers deploy agile methodologies like unittest-driven development and pair-
-programming. By the end of the project we expect to have produced more than 3000 unittests
-testing every aspect of the runtime system. The presence of such tests also allows to rapidly
-change parts of the implementation without fear of breaking functionality elsewhere. We also
-plan to release our runtime system often and thus gather additional feedback from early
-adopters, developers and researchers.
-
-To support the open development we base all of our documents, source code and website
-information on a version control system. In combintation with a notification on all changes
-this ensures that all interested parties can review and react to developments.
-
-The PyPy developers have produced a working prototype within four one-week sprints and a
-little development in between. The code and design quality of the project is already widely
-accepted. There are now 400 unittests. As a consequence, Guido van Rossum, the inventor
-and maintainer of today's Python, listed is as the number one project he would like to succeed.
-He previously attended one of our sprints and got deeply involved with our architecture and
-source code which he immediately found intuitive to work with.
-Thus we believe that our choices for technical quality management are fit to meet highest
-standards.
-
-Additional Quality procedures
-++++++++++++++++++++++++++++++++++
-
-The project manager will circulate a draft Quality Management plan for the project prior to
-first Project Meeting and and then present it for approval at the first Meeting. It should
-complement the prescribed quality approach with respect to the following aspects:
-
-o Document procedures, standards and control
-o Issue control for documents
-o Reporting procedures, frequency and format
-o Communication procedures
-o Corrective actions
-o Exception control
-o Conflict resolution
-o Meeting draft agenda
-o Format of meeting minutes
-o Tracking system for actions
-o Risk assessment
-o Evaluation routines
-o Specific responsibilities within the project
-
-:DELETE:BEGIN
-
-B 5.6 Communication and reporting
-
-:DELETE:END
-
-Communication and reporting
----------------------------------
-
-The project process will be reported as follows:
-
-o monthly written status reports to the Management Board/Technical Board by the
- project management team. These reports will be posted on the internal project
- web for the entire team to access.
-
-o project review report to the EU project office. These reports are the result
- of the project review workshops (every 6th month) and are produced by the
- project management team. These reports will be posted on the internal project
- web for the entire team to access.
-
-o Project evaluation report. At the end of the project, an evaluation report
- will be produced in which both product, process and deliverables will be
- evaluated. This report will be presented to stakeholders (consortium companies
- and partners) and the EU project office.
-
-The technical development of PyPy is driven by open continous discussion. Many of the
-involved decisions are made and verified during one-week working meetings, so called
-"sprints". Members from the larger Python software community are publicly invited and have
-the chance to interact and work with the PyPy developers or become one themselves.
-Mailing lists, chat-sessions, Wikis and notification of program changes provide a constant
-flow of information between PyPy project members and the wider community. Additionally,
-groups of developers can start interactive "screen" sessions which allows sharing their
-workspace and implement and communicate efficiently. Therefore conflicts out of missing or
-conflicting information or due to misunderstandings will be minimized.
-
-Each sprint meeting is planned for by all developers. The sprint goals are usually agreed upon
-before the meeting starts. This is also important to allow new developers or contributors to
-join specific efforts. Sprint results are subsequently published to email and web-channels to
-gather feedback and educate others about changes.
-
-We will present multiple reports and scientific papers on major conferences such as
-EuroPython (Python's european community conference), OSCON (Open Source Convention),
-PyCon (python developer conference) and to domain specific audiences such as embedded
-
-device developers.In a later phase of the project the PEP (Python Enhancement Proposals)
-procedures may be implemented. This is the standard procedure for applying changes to the
-C-implementation of Python as of today. It forces an author to clearly state the benefits of the
-proposed Enhancement and provides an rationale. However, such a formal method will only
-by required when the project reaches the point where users begin to rely on aspects of our
-implementation.
-
-:DELETE:BEGIN
-
-B 5.7 Consortium dont write
-
-B 5.8 Ip dont write
-
-:DELETE:END
Modified: pypy/trunk/doc/funding/B5.0_manage_bea.txt
==============================================================================
--- pypy/trunk/doc/funding/B5.0_manage_bea.txt (original)
+++ pypy/trunk/doc/funding/B5.0_manage_bea.txt Fri Oct 10 18:01:12 2003
@@ -484,6 +484,52 @@
B 5.7 Consortium dont write
-B 5.8 Ip dont write
+B 5.8 Ip
:DELETE:END
+
+Management of Knowledge and Intellectual Property
+--------------------------------------------------
+
+Every contributor is fully responsible for not introducing program code
+which might infringe third party copyright or patents for that matter.
+Every contributor agrees to license his contributions under a MIT-style
+license (approved by the Open Source Initiative)::
+
+ The MIT License
+
+ Copyright (c) <year> <copyright holders>
+
+ Permission is hereby granted, free of charge, to any person
+ obtaining a copy of this software and associated documentation
+ files (the "Software"), to deal in the Software without
+ restriction, including without limitation the rights to use,
+ copy, modify, merge, publish, distribute, sublicense, and/or
+ sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice shall be included
+ in all copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+
+The public availability of PyPy's source code at all times on the basis
+on such an open and commercially exploitable license stipulates exchange
+of ideas, contribution to the project and reusing all parts of PyPy from
+the start.
+
+In return, this provides the developers with fast feedback and
+improvements with respect to their current developments. At the heart of
+a free software community lies open communication, the free flow of
+information and organizing shared interests. The PyPy project is already
+fully involved and based on these principles. We also believe that for
+a language runtime system like PyPy a free license is of vital
+importance to reach wide deployment and recognition. Such a license is
+also a neccessity to allow PyPy to become a reference implementation of
+the Python language specification.
Deleted: /pypy/trunk/doc/funding/B5.1_project_manager.txt
==============================================================================
--- /pypy/trunk/doc/funding/B5.1_project_manager.txt Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,78 +0,0 @@
-FIXME JACOB
-B.5.1 Project Manager
-
-Every project must have a Project Manager. He will be responsible for
-the Management of the Project and execution of the contract. He
-is appointed by the Co-ordinator and chairs the Management
-Meetings. He approves all outputs and reports, is the prime
-external interface and also may be the Technical Director (if one
-is deemed necessary).
-
-
-There is some confusion as to the role of the Project Manager. This is
-not an administrative chore. A Project Manager will require some
-administrative support, but that is far from the essence of the job.
-The administrative functions such as status tracking, financial
-reporting, change control and project library maintenance are really a
-minor part of the overall job.
-
-Project management activities
-
-Specific targeted research projects will also include an overall
-management structure. Over and above the technical management of
-individual work packages, an appropriate management framework linking
-together all the project components and maintaining communications
-with the Commission will be needed.
-
-Project management will include:
-
-· co-ordination of the technical activities of the project;
-
-· the overall legal, contractual, ethical, financial and administrative
- management of the project;
-
-· preparing, updating and managing the consortium agreement between
- the participants;
-
-· co-ordination of knowledge management and other innovation-related
- activities;
-
-· overseeing the promotion of gender equality in the project;
-
-· overseeing science and society issues, related to the research
- activities conducted within the project;
-
-· obtaining audit certificates (as and when required) by each of the
- participants;
-
-· bank guarantees for SMEs (if applicable).
-
-Successful Project Management of a FrameWorkprogram Project
-requires various skills and knowledge. In my view it requires a
-person with the following attributes
-
- · Good appreciation of the relevant business area
-
- · Participation in a previous Framework project
-
- · Knowledge of Framework procedures
-
- · Good interpersonal skills
-
- · Well organised and systematic in own work
-
- · Good knowledge of ISO 9001
-
- · Good knowledge of English
-
- · Some knowledge of project technical area
-
- · Some knowledge of financial management
-
-Project Management is a combination of all of the above skills. Extra
-strength in some areas could compensate for weakness in others.
-Remember this function includes legal responsibility aspects and thus
-keeping of good records is essential. Any telephone calls and
-agreements, especially with the Project Officer should be minuted
-and/or confirmed in writing, at least by email.
-
Modified: pypy/trunk/doc/funding/B5.2_management_structure.txt
==============================================================================
--- pypy/trunk/doc/funding/B5.2_management_structure.txt (original)
+++ pypy/trunk/doc/funding/B5.2_management_structure.txt Fri Oct 10 18:01:12 2003
@@ -1,3 +1,5 @@
+FIXME WRITE ME !! and stick the result into B5.0
+
Management Structure
====================
Deleted: /pypy/trunk/doc/funding/B5.4_meetings.txt
==============================================================================
--- /pypy/trunk/doc/funding/B5.4_meetings.txt Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,59 +0,0 @@
-Project Meetings
-================
-
-The Management Board will meet at the start of the project and two
-times per year or on an ad hoc basis as requested. The meetings will
-normally be scheduled to rotate between countries of the EU and mainly
-the principal contractors home base.
-
-FIXME Extend?
-
-
-"Sprint" Meetings are the key to PyPy's technical development
--------------------------------------------------------------
-
-Key to PyPy's technical development and research are so called "sprints". These publically
-announced one-week meetings serve as an intense working forum to rapidly discuss
-and implement key PyPy ideas with agile methodologies. Developers usually pair
-up and write unit-tests to test the to-be-implemented features before actually adding
-them. The unittest-first approach helps to understand the planned feature. Additionally,
-the discussion in a pair makes sure that obviously wrong pathes of development are
-avoided. If something seems too hard to test or to pin down explicitely this is
-taken as an indication of an underlying design problem.
-
-Note that more traditional approaches usually follow a model where developers work alone
-and only meet to talk. Instead with sprint-driven development talking and actually
-implementing resulting ideas ensures a more focused approach with fast feedback cycles.
-While the free software community is successful especially because of it's open
-communication model sprints are an accelerator to this process. While coding in pairs
-developers educate each other which leads to a broader common understanding of the project.
-During a sprint multiple pairs want to work in parallel which adds pressure on design
-decisions so that independent development of components of the system is possible.
-Thus sprints not only deepen the communication and understanding among researchers and
-developers but they imply a working process which enhances the software design in multiple ways.
-
-With a very-high-level-language like Python rapid development in coding-sprints becomes
-especially effective. A VHLL-language generally allows to focus on ideas rather than on low-level
-language details. In combintation with pervasive test-driven development this eases high-quality
-rapid evolution towards the intendent goals. Obviously, the PyPy developers are very experienced
-with Python and bigger applications in general. Thus the full potential of agile methodologies is
-unvealed during PyPy sprints. In less than five weeks worth of development (during four sprints)
-the group produced a working prototype which is a big success not only in the eyes of its
-developers.
-
-
-Technical decisions
--------------------
-
-Major design or technical decisions are usually reached through consensus
-during the sprints. If a conflict cannot be resolved there then the technical
-board gets the final say. The members of the technical board are appointed by
-a vote of everyone who has commit rights to the source repository. However,
-it is expected that design and implementation choices will usually be
-determined by consensual agreement or by informal votes on the development
-mailing list. This is common practice within the Python and many others free
-softare communities. Also, the PyPy developers and researchers will construct
-few if any formal hierarchies between them. Constantly working together with
-agile methodologies and the visilibity of each individual contribution help
-enforce high-quality program code and good design decisions.
-
Deleted: /pypy/trunk/doc/funding/B5.5_quality.txt
==============================================================================
--- /pypy/trunk/doc/funding/B5.5_quality.txt Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,56 +0,0 @@
-
-Quality control of technical development
-----------------------------------------
-
-The PyPy project will ensure quality by a variety of means. On the grand
-scale, the involvement of excellent researchers ensures that the general
-direction takes care of latest insights in language research. Moreover,
-we will publish our research results on conferences and to scientific
-and free software communities. This forms the basis to maintain a high-quality
-general technical direction.
-
-The developers deploy agile methodologies like unittest-driven development
-and pair-programming. By the end of the project we expect to have produced
-more than 3000 unittests testing every aspect of the runtime system. The
-presence of such tests also allows to rapidly change parts of the implementation
-without fear of breaking functionality elsewhere. We also plan to release
-our runtime system often and thus gather additional feedback from early
-adopters, developers and researchers.
-
-To support the open development we base all of our documents, source
-code and website information on a version control system. In combintation
-with a notification on all changes this ensures that all interested parties
-can review and react to developments.
-
-The PyPy developers have produced a working prototype within four one-week
-sprints and a little development in between. The code and design quality
-of the project is already widely accepted. There are now 400 unittests.
-As a consequence, Guido van Rossum, the inventor and maintainer of today's
-Python, listed is as the number one project he would like to succeed. He
-previously attended one of our sprints and got deeply involved with our
-architecture and source code which he immediately found intuitive to work with.
-
-Thus we believe that our choices for technical quality management are fit
-to meet highest standards.
-
-
-
-Additional Quality procedures
-------------------------------
-
-The project manager will circulate a draft Quality Management plan
-for the project prior to first Project Meeting and and then present it
-for approval at the first Meeting. It should complement the prescribed
-quality approach with respect to the following aspects:
-
- · Document procedures, standards and control
- · Issue control for documents
- · Reporting procedures, frequency and format
- · Communication procedures
- · Corrective actions
- · Exception control
- · Conflict resolution
- · Meeting draft agenda
- · Format of meeting minutes
- · Tracking system for actions
- · Specific responsibilities within the project
Deleted: /pypy/trunk/doc/funding/B5.6_communication.txt
==============================================================================
--- /pypy/trunk/doc/funding/B5.6_communication.txt Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,34 +0,0 @@
-B.5.6 Communication and Reporting.
-
-The technical development of PyPy is driven by open continous discussion.
-Many of the involved decisions are made and verified during one-week
-working meetings, so called "sprints". Members from the larger Python
-software community are publicly invited and have the chance to interact
-and work with the PyPy developers or become one themselves.
-
-Mailing lists, chat-sessions, Wikis and notification of program changes
-provide a constant flow of information between PyPy project members and
-the wider community. Additionally, groups of developers can start
-interactive "screen" sessions which allows sharing their workspace and
-implement and communicate efficiently. Therefore conflicts out of missing
-or conflicting information or due to misunderstandings will be minimized.
-
-Each sprint meeting is planned for by all developers. The sprint goals
-are usually agreed upon before the meeting starts. This is also important
-to allow new developers or contributors to join specific efforts.
-Sprint results are subsequently published to email and web-channels to
-gather feedback and educate others about changes.
-
-We will present multiple reports and scientific papers on major
-conferences such as EuroPython (Python's european community conference),
-OSCON (Open Source Convention), PyCon (python developer conference) and to
-domain specific audiences such as embedded device developers.
-
-In a later phase of the project the PEP (Python Enhancement Proposals)
-procedures may be implemented. This is the standard procedure for
-applying changes to the C-implementation of Python as of today.
-It forces an author to clearly state the benefits of the proposed Enhancement
-and provides an rationale. However, such a formal method will only by
-required when the project reaches the point where users begin to rely
-on aspects of our implementation.
-
Deleted: /pypy/trunk/doc/funding/B5.8_ip.txt
==============================================================================
--- /pypy/trunk/doc/funding/B5.8_ip.txt Fri Oct 10 18:01:12 2003
+++ (empty file)
@@ -1,42 +0,0 @@
-B.5.8 Management of Knowledge and Intellectual Property
-
-Every contributor is fully responsible for not introducing program code
-which might infringe third party copyright or patents for that matter.
-Every contributor agrees to license his contributions under a MIT-style
-license (approved by the Open Source Initiative)::
-
- The MIT License
-
- Copyright (c) <year> <copyright holders>
-
- Permission is hereby granted, free of charge, to any person
- obtaining a copy of this software and associated documentation
- files (the "Software"), to deal in the Software without
- restriction, including without limitation the rights to use,
- copy, modify, merge, publish, distribute, sublicense, and/or
- sell copies of the Software, and to permit persons to whom the
- Software is furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be included
- in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- DEALINGS IN THE SOFTWARE.
-
-The public availability of PyPy's source code at all times on the basis on such
-an open and commercially exploitable license stipulates exchange of ideas,
-contribution to the project and reusing all parts of PyPy from the start.
-
-In return, this provides the developers with fast feedback and improvements with
-respect to their current developments. At the heart of a free software community
-lies open communication, the free flow of information and organizing shared
-interests. The PyPy project is already fully involved and based on these principles.
-We also believe that for a language runtime system like PyPy a free license
-is of vital importance to reach wide deployment and recognition. Such a license
-is also a neccessity to allow PyPy to become a reference implementation of the
-Python language specification.
More information about the Pypy-commit
mailing list