remove invalid xml file

1 files changed, 0 insertions, 322 deletions

diff --git a/xml/htdocs/proj/en/lead/dev-project-stds.xml b/xml/htdocs/proj/en/lead/dev-project-stds.xml
deleted file mode 100644
index 1c4c9f83c5..0000000000
--- a/xml/htdocs/proj/en/lead/dev-project-stds.xml
+++ /dev/null
@@ -1,322 +0,0 @@
-This document contains comprehensive standards for Gentoo software development
-projects. These standards should benefit nearly any Gentoo project, but are
-particularly critical for projects that demand a very high level of refinement
-and overall quality.
-
-Goals
-
-The goal of this development standards document is to provide a template for
-software development efforts that, when followed, will produce the best
-possible results for Gentoo. It is intended to define a waterfall model for
-Gentoo (with spiral aspects in appropriate places) to address the challenges
-and user expectations of Gentoo's volunteer, community-based development model.
-Often, it is the attention paid to details that make a difference, and this is
-particularly true of software engineering. This document also attempts to
-address those little details that can have a very large impact on the success
-or failure of software development efforts.
-
-First Steps
-
-Before starting any development project, try to get a good general idea of the
-goal of the project. What is the purpose of this effort? What parts of Gentoo
-will be interested in this development effort? Once you have a good high-level
-understanding of the effort, it's time to begin the process of formally
-defining the characteristics, goals and requirements of your project.
-
-Target Audience
-
-A critical first step is to clearly define the target audience of your
-development effort. 
-
-If your development effort will focus on producing an enhanced version of a
-tool that is already being used by many Gentoo users, then your target audience
-will generally include the Gentoo users who are already using the current
-version of the tool. In turn, your development process should invite
-participation from this community.  (Note: designing a "next-generation"
-version of an existing tool has a number of potentially serious pitfalls.
-Please be sure to read the "Second System Effect" section in this document particularly 
-carefully in this case.)
-
-The most obvious example of this principle relates to the development of Portage.
-Because Portage is used by nearly every Gentoo user, a development effort
-related to improving Portage would generally include the entire Gentoo user
-community as the target audience. 
-
-Since the success or failure of any effort to improve Portage will be
-determined by how well it meets the requirements of the Gentoo user community,
-it will be of great benefit to gather as much input as possible from Gentoo
-users. Any changes should be acceptable to the Gentoo user community as a
-whole.
-
-On the other hand, if you are developing a new piece of software that does not
-have an already-established user community, you may determine that it is best
-to choose a more select group (such as a group of developers) as your target
-audience.  Often, this is the most practical choice when you are creating a
-toolkit or engine that requires some level of technical expertise to use, and
-which may be used to produce products that are in turn delivered to the user
-community.  In time, your software may develop its own user community. At this
-point, your target audience can be widened to include these users, who can then
-participate in future development efforts.
-
-One example of a development effort that was started without an existing user
-community is the catalyst build tool, which is used to build official Gentoo
-stages and LiveCDs. Very few Gentoo developers (let alone users) are familiar
-with the complex details involved in building stages and LiveCDs, so there was
-little benefit to be had in trying to invite input from regular Gentoo users in
-the design and development of catalyst.  However, as catalyst begins to develop
-its own community of dedicated users, this will change. When a catalyst user
-community exists, it will be considered part of the target audience for any
-future development and these users will be invited to participate in defining
-goals and requirements for future development. 
-
-Specific ways to involve users in the development process of your software are
-included throughout this document.
-
-Another example of the "no existing user community" situation is the Gentoo
-Installer project. While at first read it may seem as if the Installer project
-should be squarely aimed at Gentoo users (and thus Gentoo users should be
-included in the target audience from the start,) it was decided that the most
-effective course of action was to develop an Installer _Engine_.  This Engine
-would be used by developers to build installers for end-users.
-
-Because the high-level goal of this effort is to build an Installer Engine or
-toolkit (rather than an individual installer,) the target audience was chosen
-to be a group of Gentoo developers who will be using this tool initially. In
-time, as Gentoo users start using this tool to create their own custom
-installers, the target audience for the development effort will widen to
-include them. This will allow future developments to be responsive to their
-needs and requests.
-
-Invite Participation 
-
-The next step is to invite the participation of your target audience. You
-definitely want your target audience to participate in defining the goals of
-your effort. Members of your target audience could also conceivably create a
-prototype, or even assist with the architecting or implementation of the actual
-program.
-
-The purpose of inviting participation is twofold. First, if your target
-audience needs a particular capability, it is best to know about it sooner
-rather than later. Second, volunteer projects are often limited by resources,
-and inviting participation is a great way to start getting an idea as to the
-resources you have, which will help you to set a reasonable design and
-development schedule. Third, because Gentoo is a community project, open
-participation is a way of keeping the community informed. Quite a few
-participants may not contribute requests for functionality or assist with
-design or implementation, but at the very least they will be apprised of what
-is going on with your effort. Keeping the community informed of what you are 
-working on is very beneficial to the project as a whole.
-
-The best way to invite participation is to start a decicated mailing list (and
-possibly irc channel) devoted to your effort, or to use an appropriate existing
-"special purpose" mailing list. Inform anyone in your target
-audience who wants to be involved to join this list. Make sure that your
-invitation extends to your entire target audience, and consider posting a
-www.gentoo.org news item or GWN article about the effort to invite
-participation if appropriate.
-
-Create a High-Level Development timeline
-
-Next, develop a tenative development roadmap for your effort that sets general
-completion dates for:
-
-1) project start (public invitation)
-2) initial work on design/requirements doc
-3) completion of design/requirements doc (should be at least a month after #2)
-
-In addition, your roadmap should also define how the design, development and
-testing process should proceed, so it should define steps such as:
-
-4) implementation proposal process
-5) review process
-6) prototype implementation
-7) prototype test
-8) final implementation
-9) final test
-
-Of course, until you know what you are designing, it is hard to define a
-development schedule. Steps 4 and beyond will need to have very tenative dates
-associated with them at first, if any at all.
-
-Also note steps 7 and 9 above. They are steps that involve performing testing
-and QA on the results of your work. It's important to build testing and QA into
-your development schedule, and not tack it on as an afterthought. Not doing so
-has a tendency to derail projects as they enter later stages of development.
-Plan on spending a solid 50% of your development effort on testing, QA and bug
-fixing. Yes, that is a large percentage, but projects that allow for a lot of
-testing, QA and bug fixing are generally more likely to be successful than
-those that don't.  And if you do your job right, not all of the allotted time
-will be needed and your project will finish early.  Also, as humans we have a
-tendency to forget that we are not perfect, and that our implementations can
-(and generally do) require a significant number of bug fixes and enhancements
-before being production-ready.
-
-As the project progresses, you may need to review your timeline and make
-adjustments.  It is OK to make changes. But it is essential to always have a
-documented timeline that indicates when you currently expect to complete each
-plannable aspect of the development effort. You should always have a clear set
-of dates that you're shooting for -- otherwise your development effort runs the
-risk of not having a clear focus.
-
-Gentoo is a volunteer project, and the nature of volunteer work can make it
-quite challenging to meet deadlines. Fortunately, there are quite a few
-techniques that can be used to make your development effort resilient, so that
-it can meet the unexpected challenges of volunteer development, whether this
-means flexibility in dealing with needed adjustments to deadlines, coping with
-changes in developer interest and activity, etc.
-
-One absolutely critical aspect to ensuring success in an uncertain environment
-is to *clearly define the requirements for the results of your effort*.  "Hard
-requirements" are specific, testable aspects of your end-product -- aspects
-that must be achieved in order for your development effort to be considered a
-success. If you're behind schedule, you can't compromise on a hard requirement
--- doing so would undermine the entire purpose of the development effort. Instead,
-your schedule will need to be adjusted to reflect the your current progress. 
-
-You need to have all your hard requirements documented before actual coding
-begins, so you have a clear goal for your effort. This will prevent feature
-bloat and ensure that you have a clear, focused development plan and that
-your progress towards the goal can be ascertained.
-
-On the other hand, _soft_ requirements are somewhat negotiable. If your project
-is at risk of falling behind schedule, you may choose to waive one or several
-of your soft requirements in order to allow your team to complete your project
-on time. It's also possible that you may choose not to abandon any of your soft
-requirements if, for example, your development project isn't particularly
-time-sensitive. Like hard requirements, soft requirements should also be
-defined before coding begins.  That way, if compromises need to be made, your
-effort already has clearly-defined "crumple zones."
-
-Efficient Teams, Conceptual Integrity
-
-As your development effort begins, you're going to need to assemble some kind
-of capable team to do the necessary planning (and then organization, coding and
-testing.) The aspects of the development process described so far have
-been very "open." You've been encouraged to include as many people as possible
-in the development effort, and start documenting the needs of your target
-audience (we'll be covering more on this in the next section.)
-
-Not every aspect of your effort will need to be as open as possible. Yes, there
-are certain aspects that do need to be as open as possible, such as defining
-requirements for your development effort. But when it becomes time to define
-the final production architecture and then code your program, you're going to
-need to temporarily shut your doors to any significant outside participation.
-At that point, you want to have as <i>small</i> a team as possible working on
-the code. So enjoy the public participation while you can and make sure you
-understand the needs of your target audience, because at a certain point this
-open participation will need to be put on hold. Then your team's focus will
-shift inwards, towards implementing the program as per the documented
-requirements and design goals.
-
-This may seem very odd, but here's the reason why you want a very small
-development team. Smaller teams are generally much more productive than large
-teams. There's less overhead involved in keeping everyone informed about what's
-going on. Decisions can be made more quickly. Coordination is easier. Try
-to keep your core development team at 10 people or less.
-
-For your final implementation, I recommend that you have <b>one</b> designated
-implementation architect/builder. The implementation will be completed by this
-one person.  This is actually a very beneficial aspect to a successful development
-effort because it ensures that your effort is capable of having <i>conceptual
-integrity</i>.  Conceptual integrity is an important aspect of
-software design -- it means the thing you are designing, taken as a whole,
-makes sense and works together like a well-oiled machine.
-
-If you do not have a single person in charge of implementation, you
-risk creating a situation where there is no one person in your effort with a
-complete, authoritative vision for the implementation of the software you
-are creating. This is a very dangerous condition, as it can result in software
-that functions like a mish-mash of parts, doesn't work well, and isn't completed
-on-time.
-
-Here's why small teams and a single implementation architect can be very efficient.
-With this model, every little detail related to implementation does not need
-to be documented and communicated to a large number of people. Communication has
-the potential of taking up a huge amount of resources during the implementation
-phase when there are a massive number of details and decisions that need to be made.
-Small teams and a single implementation architect allow the implementation effort
-to be as efficient and cohesive as possible.
-
-Please note that I am not saying that one person should do all the work. You
-can compare the "single architect/builder model" to that of a surgical team.
-One lead surgeon directs the surgery and generally performs all the incisions.
-The lead surgeon is always aware of the state of the patient, and he or she
-is ultimately responsible for the patient's well-being.
-But there are also other surgeons involved. Some are providing direct
-assistance to the lead surgeon. Others are reviewing the surgeon's work to
-ensure that it is performed correctly. There are also support staff who are
-providing adequate materials to the surgeon so that he can work as efficiently
-as possible and focus on the task at hand.
-
-Likewise, your team can have one person who is in charge of
-implementation/coding and still truly be a team. The other team members can and
-should review the architect's work and offer their feedback and suggestions.
-There should be some built-in process to allow this kind of peer-review.
-Some team members may have a very good grasp of the implementation programming
-language or various programming techniques and offer good suggestions on how to
-improve the implementation.  Others may suggest a change in approach that could
-improve maintainability of the code.  The implementation team needs to work
-together to produce the best possible result.  But the incisions should all be
-made by or at the very least at the direction of the lead surgeon; otherwise
-there is a risk that your team will be uncoordinated or waste an uncessarily
-large percentage of effort on coordination and communication tasks. This could
-have an adverse impact on the health of the patient, which in this case is the
-software that is being developed.
-
-Everyone on the team should have an opportunity to help improve the
-implementation, but only one person (or as few as possible) should actually be
-doing the implementing. This will allow the implementors to work efficiently.
-
-Here are some suggested roles for the members of your development effort:
-
-1) Architect/builder: responsible for the implementation (both the design
-of the implementation and actually doing the implementing.)
-This person will be doing the majority of the coding, and will also write
-the initial (possibly rough) documentation. This person has final authority
-over the implementation of the software.
-
-2) Assistant architect: reviews the work of the Architect, audits the integrity
-fo the Architect's work and handles administrative and planning efforts while
-the Architect is busy working on the code. Has a very good understanding of the
-vision and implementation plan so that he/she can substitute for the Architect
-in emergencies.  Can act as liaison for any bug reports or hashing out of
-feature requests so that the Architect receives this feedback in a refined
-(rather than rough) form. 
-
-3) Language/design lawyer: Periodically reviews the implementation and offers
-feedback on better use of language constructs or design, with an eye towards
-improving maintainability, performance, code reuse, coding efficiency and/or
-better meeting the design requirements.
-
-4) Documentation Lead: Responsible for taking the Architect/builders's rough
-initial documentation and creating high-quality documentation suitable for public
-consumption. This may involve creating a new manual geared towards users rather
-than developers.
-
-Please note that it is possible to have a successful development effort that has
-a team of two people: a Lead Architect and Assistant Architect. In fact, a team size
-of two tends to be extremely efficient. Don't fear small teams; instead, keep your
-implementation team as small as practically possible.
-
-I believe that one thing that made Portage well-received by the public was the
-attention to conceptual integrity that went into its design. Portage provides a
-set of capabilities that work together quite well.  Over the years, various
-features have been grafted in to Portage, some more successfully than others.
-The features that were integrated well were those in which considerable
-attention was paid to protecting the conceptual integrity of Portage. Because
-these feature additions made sense as part of a larger whole, they improved the
-utility of the entire program.
-
-Often, it's not the number of features that define the quality of a piece of
-software, but rather how well the relatively few features that exist complement
-one another. In the same sense, the number of developers on your implementation
-team generally does not corollate to the overall pace of development or the
-quality of the implementation. Keep these things in mind, particularly in the
-planning stages.
-
-The Second System Effect
-
-Defining Requirements
-
-The Requirements Specification Document
-