Return-Path:
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
by cust-asf2.ponee.io (Postfix) with ESMTP id 9510F200CB1
for ; Sat, 24 Jun 2017 13:32:11 +0200 (CEST)
Received: by cust-asf.ponee.io (Postfix)
id 9383E160BF6; Sat, 24 Jun 2017 11:32:11 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by cust-asf.ponee.io (Postfix) with SMTP id 8A4DC160BDA
for ; Sat, 24 Jun 2017 13:32:09 +0200 (CEST)
Received: (qmail 16141 invoked by uid 500); 24 Jun 2017 11:32:08 -0000
Mailing-List: contact cvs-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: general@incubator.apache.org
Delivered-To: mailing list cvs@incubator.apache.org
Received: (qmail 16132 invoked by uid 99); 24 Jun 2017 11:32:08 -0000
Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Jun 2017 11:32:08 +0000
Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33)
id CEE1CE02B4; Sat, 24 Jun 2017 11:32:07 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: johndament@apache.org
To: cvs@incubator.apache.org
Date: Sat, 24 Jun 2017 11:32:07 -0000
Message-Id: <679d5320430047c7bd20e766cb2b9722@git.apache.org>
X-Mailer: ASF-Git Admin Mailer
Subject: [1/3] incubator git commit: Continued converting pages to new layout
and technology.
archived-at: Sat, 24 Jun 2017 11:32:11 -0000
Repository: incubator
Updated Branches:
refs/heads/jbake-site 64a97b9d4 -> e258a499f
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/proposal.xml
----------------------------------------------------------------------
diff --git a/pages/guides/proposal.xml b/pages/guides/proposal.xml
deleted file mode 100644
index 77d2a66..0000000
--- a/pages/guides/proposal.xml
+++ /dev/null
@@ -1,1045 +0,0 @@
-
-
-
-
-]>
-
-
-
- A Guide To Proposal Creation
- general@incubator.apache.org Archives
-
-
-
- A Guide To Proposal Creation
- Contents
-
- Status
-
-This document provides guidance only. Policy is found here.
-
-
-
- Abstract
-
-This document is descriptive, not normative. It describes approaches to
-drawing up a proposal for submission. It is not an inflexible standard but
-represents a consensus condensed from discussions on the
-general mailing list.
-
-
-
- Background
-
-Entry to the incubator is a democratic
-process decided by a vote.
-The proposal is the document upon which the
-Sponsor votes.
-So, though it's neither necessary nor sufficient to have a good proposal,
-a good proposal increases the chances of a positive result.
-
-
-Proposals to the incubator generate attention. The
-general mailing list is open,
-widely discussed and well indexed. It is a very public space.
-The proposal is a manifesto.
-A good proposal should target also the wider audience and not just the
-
-jury.
-Use this time to engage and inform potential
-developers
-and users.
-
-
-Much of the information will be reused in the
-Podling website.
-A good proposal should shape the future evolution of the project
-but each proposal captures only the particular instant at birth.
-It is understood that projects change and evolve.
-
-
- Continuous Improvement
-
-The Incubation process is continuously evolving.
-Hopefully this will help newer projects to be even stronger and more successful then existing ones.
-One consequence of this approach is that precedence is not always a reliable guide.
-Another is that documentation may be a little outdated.
-
-
-
- Help Wanted!
-
-Help to improve the system by posting a patch for this document to the
-incubator section
-of JIRA
-or a comment to the general list.
-
-The incoming community needs to work together before presenting this
-proposal to the incubator. Think about and discuss future goals and the reasons for coming to Apache.
-Feel free to ask questions on list.
-
-
-Every proposal is different. There will always be some aspects which do not seem
-to fit well into the template.
-Use the template as a guide but do not feel constrained
-by it. Adopt what works and change what doesn't. That's fine - in fact, it's expected.
-
- While it is important to ensure a
- suitable project name
- and product names sometime during incubation, it is not necessary
- to do this prior to entering incubation. In fact, be careful not to
- disrupt your proposal and entry process.
-
-
- Presentation
-
-Once the preparatory work is done, the proposal should be presented to the
-incubator. Post the proposal in plain text in an email to the
-mailing list
-whose subject is prefixed with [PROPOSAL]. You should be clear
-that you want to discuss your proposal when submitting this mail.
-
-
-If there is interest in the proposal, expect a lively debate to begin.
-Approval is an open and
-democratic
-process.
-Discussion is an important part of opinion formation. A proposal
-will require development if it is to gain the maximum level of support from the
-electorate.
-
-
- Developing The Proposal
-
-Expect to work on improving the proposal on the list after presenting it.
-No preparation can cover every question. It is usual for unexpected
-and novel questions to be asked. This is often a sign of interest. So
-(though it may sometimes feel like an ordeal)
-approach these questions as a positive opportunity.
-
-
-The wiki is a good
-development tool. Consider creating a wiki page containing the evolving proposal
-content. Those who are interested should add themselves
-to the watch list for the page so they can receive change notifications.
-
-
-Developing the proposal on the wiki allows easy collaboration. This has disadvantages
-as well as advantages. The wiki is just a tool to assist the easy development of the
-final proposal (the one that will be voted upon). Not every change improves a proposal
-and there is no requirement that every change is accepted by the proposers. Note that the incubator
-asks all participants to abide by appropriate netiquette.
-
-
-Effective management of this development is an exercise in community building.
-The wiki is not an appropriate forum for debating changes. Discussion should be
-gently moved onto the appropriate
-mailing list.
-
-
- The Vote
-
-When the proposal seems finished and some sort of consensus has emerged, the
-proposal should be put to a vote.
-
-If the wiki is used to develop the proposal, please ensure that the wiki
-matches the final proposal then add a notice to the wiki that development of
-the document is now complete:
-
-
-
-Embed the final proposal text or a link to a specific revision number of the
-wiki proposal page in the email which kicks off the VOTE thread. If a change
-is required after the vote has been called then the vote must be cancelled,
-the change made, and the vote restarted. Alternatively, Mentors will advise
-on how to make the change once the proposal has been accepted if this is
-appropriate. Do not edit the wiki proposal unless you cancel the vote
-thread.
-
-
-
-
- Proposal Template
-
-The aim of presenting a template with examples and comments is educational.
-Proposals are not required to adopt this format.
-Every proposal is different. There may be sections which don't seem to be
-useful. It's fine to miss them out and to add new ones that the proposal seems
-to need. Best practice evolves. Innovation is acceptable.
-
-
-The format is less important than the content.
-
-
-In the following sections:
-
-
-
-Commentary is thus.
-
-
-
- Abstract
-
-
-A short descriptive summary of the
-project. A short paragraph, ideally one sentence in length.
-
-The abstract should be suitable for reuse in
-the board resolution used to create the official project upon graduation,
-as the first paragraph on the podling web site
-and in the DOAP document.
-
-
-
-
- Proposal
-
-
-A lengthier description of the proposal. Should be reasonably declarative.
-More discursive material should be included in the rationale
-(or other later sections).
-
-
-
-
- Background
-
-
-Provides context for those unfamiliar with the problem space and history.
-
-Explain terms whose meanings may be misunderstood (for example,
-where there is not a single widely adopted definition).
-
-
-This content should be capable of being safely ignored by domain experts.
-It should probably find an eventual home on the Podling website.
-
-
-
-
- Rationale
-
-
-Explains why this project needs to exist and why should it be adopted by Apache.
-This is the right place for discursive material.
-
-
-
-
- Initial Goals
-
-
-A complex proposal (involving multiple existing code bases, for example)
-may cause concerns about its practicality. A good way
-to address these concerns is to create a plan that demonstrates the proposal
-is feasible and has been carefully thought through.
-
-
-Many projects will not need this section.
-
-
-
-
- Current Status
-
-
-This section (and the contained topics) describes
-the candidate's current status and development practices.
-This should be an honest assessment balancing these against Apache's
-principles and
-development ideals.
-
-For some proposals, this is a chance to demonstrate understanding
-of the issues that will need to addressed before graduation.
-For others, this is a chance to highlight the close match with Apache that already exists.
-Proposals without an initial code base should just simply state that.
-
-Some proposals name this section criteria (though the term is a little misleading).
-
-Once a developer has submitted enough good patches then it should be
-natural that they are elected to committer. It should be natural that active committers are elected
-to the project management committee (PMC).
-
-
-This process of renewal is vital to the long term health of Apache projects.
-This is the right place to demonstrate that this process is understood
-by the proposers.
-
-
-
-
- Community
-
-
-Apache is interested only in communities.
-
-Candidates should start with a
-community and have the potential to grow and renew this community by
-attracting new users and developers. Explain how the proposal fits this vision.
-
-It is useful to provide a brief introduction to the developers on the
-initial committers list.
-This is best done here (and not in that section). This section may be used to discuss
-the diversity of the core development team.
-
-
-
-
- Alignment
-
-
-Describe why Apache is a good match for the proposal.
-An opportunity to highlight links with Apache
-projects
-and development philosophy.
-
-
-
-
-
- Known Risks
-
-
-An exercise in self-knowledge.
-Risks don't mean that a project is unacceptable.
-If they are recognized and noted then they can be addressed during incubation.
-
-
- Orphaned products
-
-
-A public commitment to future development.
-
-Recruiting a diverse development community and strong user base takes time.
-Apache needs to be confident that the proposers are committed.
-
-
-
-
-
-
-
-
- Inexperience with Open Source
-
-
-If the proposal is based on an existing open source project with a history of open development,
-then highlight this here.
-
-
-If the list of initial committers contains developers
-with strong open source backgrounds then highlight this here.
-
-
-Inexperience with open source is one reason why closed projects choose to apply for incubation.
-Apache has developed over the years a store of experience in this area.
-Successfully opening up a closed project means an investment of energy by all involved.
-It requires a willingness to learn and to give back to the community. If the proposal is based
-around a closed project and comes with very little understand of the open source space,
-then acknowledge this and demonstrate a willingness to learn.
-
-
-
-
-
-
-
-
-
-
- Homogenous Developers
-
-
-Healthy projects need a mix of developers. Open development requires a commitment
-to encouraging a diverse mixture. This includes the art of working as part of
-a geographically scattered group in a distributed environment.
-
-
-Starting with a homogenous community does not prevent a project from entering incubation.
-But for those projects, a commitment to creating a diverse mix of developers is useful.
-Those projects who already have a mix should take this chance to highlight that they do.
-
-A project dominated by salaried developers who are interested in the code
-only whilst they are employed to do so risks its long term health.
-
-Apache is about people,
-not corporations. We hope that developers continue to be involved with Apache
-no matter who their current employer happens to be.
-
-
-This is a right place to indicate the initial balance between salaried developers
-and volunteers. It's also good to talk about the level of commitment of the developers.
-
-
-
-
-
-
-
-
- Relationships with Other Apache Products
-
-
-Apache projects should be open to collaboration with other open source projects both
-within Apache and without. Candidates should be willing to reach outside their own little bubbles.
-
-This is a an opportunity to talk about existing links. It is also the right place to
-talk about potential future links and plans.
-
-Apache allows different projects to have competing or overlapping goals. However, this should
-mean friendly competition between codebases and cordial cooperation between communities.
-
-It is not always obvious whether a candidate is a direct competitor to an existing
-project, an indirect competitor (same problem space, different ecological niche) or are just
-peers with some overlap. In the case of indirect competition, it is
-important that the abstract describes accurately the niche. Direct competitors should expect
-to be asked to summarize architectural differences and similarities to existing projects.
-
-
-
-
-
-
- A Excessive Fascination with the Apache Brand
-
-
-Concerns have been raised in the past that some projects appear to have been proposed
-just to generate positive publicity for the proposers. This is the right place
-to convince everyone that is not the case.
-
-This is also the right place to build bridges with the
-community after past misdemeanors (for example, if any of those associated
-with the proposal have - in the past - sort to associate themselves with the Apache brand in
-factually incorrect ways) and promise good conduct for the future.
-
-
-
-
-
-
-
-
-
- Documentation
-
-
-References to further reading material.
-
-
-
-
- Initial Source
-
-
-Describes the origin of the proposed code base. If the initial code arrives
-from more than one source, this is the right place to outline the different
-histories.
-
-If there is no initial source, note that here.
-
-
-
-
- Source and Intellectual Property Submission Plan
-
-
-Complex proposals (typically involving multiple code bases) may find it useful
-to draw up an initial plan for the submission of the code here.
-Demonstrate that the proposal is practical.
-
-
-
-
- External Dependencies
-
-
-External dependencies for the initial source is important. Only some external dependencies
-are allowed by Apache policy.
-These restrictions are (to some extent) initially relaxed
-for projects under incubation.
-
-
-If the initial source has dependencies which would prevent graduation
-then this is the right place to indicate how these issues will be resolved.
-
-
-
-
- Cryptography
-
-
-If the proposal involves cryptographic code either directly or indirectly,
-Apache needs to know so that the
-relevant paperwork can be obtained.
-
-
-
- Required Resources
-
-
-Resources that infrastructure will be asked to supply for this project.
-
-
- Mailing lists
-
-
-The minimum required lists are private@{podling}.incubator.apache.org
-(for confidential PPMC discussions)
-and dev@{podling}.incubator.apache.org lists.
-Note
-that projects historically
-misnamed the private list pmc. To
-avoid confusion over appropriate usage it was
-resolved
-that all such lists be renamed.
-
-If this project is new to open source, then starting with these minimum lists
-is the best approach.
-The initial focus needs to be on recruiting new developers.
-Early adopters are potential developers.
-As momentum is gained, the community may decide to create commit
-and user lists as they become necessary.
-
-Existing open source projects moving to Apache will probably want to adopt the
-same mailing list set up here as they have already. However, there is no necessity
-that all mailing lists be created during bootstrapping. New mailing lists can be
-added
-by a VOTE
-on the Podling list.
-
-
-By default, commits for {podling} will be emailed to
-commits@{podling}.incubator.apache.org.
-It is therefore recommended that this naming convention is adopted.
-
-
-Mailing list options are described at greater length
-elsewhere.
-
-
-
-
- Subversion Directory
-
-
-It is conventional to use all lower case, dash-separated (-) directory names.
-The directory should be within the incubator directory space
-(http://svn.apache.org/repos/asf/incubator).
-
-
-
-
- Git Repository
-
-
- It is conventional to use all lower case, dash-separated (-) repository names.
- The repository should be prefixed with incubator and later renamed assuming the project is promoted
- to a TLP.
-
-
-
-
- Issue Tracking
-
-
-Apache runs JIRA
-and Bugzilla. Choose one. Indicate the
-name by which project should be known in the issue tracking system.
-
-
-
-
- Other Resources
-
-
-Describe here any other special infrastructure requirements necessary for the proposal.
-Note that the infrastructure team usually requires a compelling argument
-before new services are allowed on core hardware. Most proposals should not require this section.
-
-
-Most standard resources not covered above (such as continuous integration)
-should be added after bootstrapping.
-The infrastructure documentation explains
-the process.
-
-
-
-
- Initial Committers
-
-
-List of committers (stating name and an email address) used to bootstrap the community.
-Mark each which has submitted a
-contributor license agreement (CLA).
-Existing committers should use their apache.org email address (since they
-require only appropriate karma). Others should use the email address that is (or will be)
-on the CLA. That makes it easy to match CLAs with proposed committers to the project.
-
-
-It is a good idea to submit CLAs at the same time as the proposal.
-Nothing is lost by having a CLA on file at Apache
-but processing may take some time.
-
-
-Note this and
-this. Consider creating a separate
-section where interested developers can express an interest (and possibly leave
-a brief introduction) or ask them to post to the
-general list.
-
-
-
-
- Affiliations
-
-
-Little bit of a controversial
-subject.
-Committers at Apache are individuals
-and work here on their own behalf. They are judged on their merits not their
-affiliations. However, in the spirit of full disclosure, it is useful for
-any current affiliations which may effect the perceived independence of the initial committers to be
-listed openly at the start.
-
-For example, those in salaried positions whose job is to work on the
-project should list their affiliation. Having this list helps to judge how
-much diversity exists in the initial list and so how much work there is to
-do.
-
-
-This is best done in a separate section away from the committers
-list.
-
-
-Only the affiliations of committers on the initial bootstrap list
-are relevant. These committers have not been added by the usual
-meritocratic process.
-It is strongly recommended that the once a project is
-bootstrapped, developers are judged by their contributions and not by their
-background. This list should not be maintained after the bootstrap has been completed.
-
-
-
- Sponsors
- Champion
-
-
-The Champion is
-a person already associated with Apache who leads the proposal process. It is common
-- but not necessary - for the Champion to also be proposed as a
-Mentor.
-
-
-A Champion should be found while the proposal is still being formulated. Their role is to help formulate the proposal and work with you to resolve comments and questions put forth by the IPMC while reviewing the proposal.
-
- Three Mentors gives a quorum and allows a Podling more autonomy from the Incubator PMC, so the current consensus is that three Mentors is a good number. Any experienced Apache community member can provide informal mentorship anyway, what's important is to make sure the podling has enough regularly available mentors to progress smoothly. There is no restriction on the number of mentors, formal or informal, a Podling may have.
-
-
-
- Sponsoring Entity
-
-
-The Sponsor
-is the organizational unit within Apache taking responsibility for this proposal.
-The sponsoring entity can be:
-
-
-
the Apache Board
-
the Incubator
-
another Apache project
-
-
-The PMC for the appropriate project will decide whether to sponsor (by a vote).
-Unless there are strong links to an existing Apache project, it is recommended that the
-proposal asks that the Incubator for sponsorship.
-
-
-Note that the final destination within the Apache organizational structure
-will be decided upon graduation.
-
-
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/retirement.ad
----------------------------------------------------------------------
diff --git a/pages/guides/retirement.ad b/pages/guides/retirement.ad
index 070c438..cca89e3 100644
--- a/pages/guides/retirement.ad
+++ b/pages/guides/retirement.ad
@@ -80,12 +80,12 @@ Any incubating releases will still be available via
link:http://archive.apache.org/dist/incubator[archive.apache.org/dist/incubator].
- Create a file RETIRED.txt at the top-level of each podling
source repository. This should contain something like the following:
-** #This podling has been retired, please see: http://incubator.apache.org/projects/index.html##{podling-name}
+** This podling has been retired, please see: http://incubator.apache.org/projects/index.html##{podling-name}
- If the podling has a DOAP referenced in the link:https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml[projects.xml] file used for generating link:http://projects.apache.org[projects.apache.org], remove the entry.
- Open a "task" INFRA JIRA ticket entitled "Retire the ${podling} Incubator podling". Open sub-tickets using "Create Sub-Task" as applicable:
** Close ${podling} mailing lists
** (If copyright task completed) Make ${podling} version control read-only
-** (If copyright task not completed) Remove ${podling} version control
+** (If copyright task *not* completed) Remove ${podling} version control
** (If JIRA) Move ${podling} JIRA to "retired" and set read-only
** (If Bugzilla) Close ${podling} Bugzilla
** Make ${podling} wiki read-only
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/website.ad
----------------------------------------------------------------------
diff --git a/pages/guides/website.ad b/pages/guides/website.ad
index bd05300..64e4e5f 100644
--- a/pages/guides/website.ad
+++ b/pages/guides/website.ad
@@ -12,7 +12,7 @@
= Updating the top-level Incubator website
Apache Incubator PMC
2002-10-16
-:jbake-type: guide
+:jbake-type: pmcGuide
:jbake-status: published
:idprefix:
:toc:
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/history/history-timeplot.js
----------------------------------------------------------------------
diff --git a/pages/history/history-timeplot.js b/pages/history/history-timeplot.js
new file mode 100644
index 0000000..fde4d4e
--- /dev/null
+++ b/pages/history/history-timeplot.js
@@ -0,0 +1,58 @@
+var timeplot;
+
+function onLoad() {
+ var timeGeometry = new Timeplot.DefaultTimeGeometry({
+ gridColor: new Timeplot.Color("#ffffff"),
+ axisLabelsPlacement: "top"
+ });
+
+ var valueGeometryCurrent = new Timeplot.DefaultValueGeometry({
+ gridColor: "#ffff00",
+ axisLabelsPlacement: "right",
+ min: 0,
+ max: 65
+ });
+
+ var valueGeometryEntry = new Timeplot.DefaultValueGeometry({
+ gridColor: "#00ff00",
+ axisLabelsPlacement: "left",
+ min: 0,
+ max: 200
+ });
+
+ var eventSourceCurrent = new Timeplot.DefaultEventSource();
+ var eventSourceEntry = new Timeplot.DefaultEventSource();
+
+ var plotInfo = [
+ Timeplot.createPlotInfo({
+ id: "plot1",
+ dataSource: new Timeplot.ColumnSource(eventSourceCurrent,1),
+ valueGeometry: valueGeometryCurrent,
+ timeGeometry: timeGeometry,
+ lineColor: "#ffff00",
+ showValues: true
+ }),
+ Timeplot.createPlotInfo({
+ id: "plot2",
+ dataSource: new Timeplot.ColumnSource(eventSourceEntry,2),
+ valueGeometry: valueGeometryEntry,
+ timeGeometry: timeGeometry,
+ lineColor: "#00ff00",
+ showValues: true
+ })
+ ];
+
+ timeplot = Timeplot.create(document.getElementById("history-timeplot"), plotInfo);
+ timeplot.loadText("current.txt", ",", eventSourceCurrent);
+ timeplot.loadText("entry.txt", ",", eventSourceEntry);
+}
+
+var resizeTimerID = null;
+function onResize() {
+ if (resizeTimerID == null) {
+ resizeTimerID = window.setTimeout(function() {
+ resizeTimerID = null;
+ timeplot.repaint();
+ }, 100);
+ }
+}
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/history/index.html
----------------------------------------------------------------------
diff --git a/pages/history/index.html b/pages/history/index.html
new file mode 100644
index 0000000..9218dde
--- /dev/null
+++ b/pages/history/index.html
@@ -0,0 +1,16 @@
+
+
+ Apache Incubator history
+
+
+
+
+
Apache Incubator history
+
+
+
yellow = Total podlings currently in incubation
+
green = Count podlings entered incubation (cumulative)
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/podling-story.ad
----------------------------------------------------------------------
diff --git a/pages/podling-story.ad b/pages/podling-story.ad
new file mode 100644
index 0000000..12480ea
--- /dev/null
+++ b/pages/podling-story.ad
@@ -0,0 +1,95 @@
+= The Story of a Podling
+Apache Incubator PMC
+2002-10-16
+:jbake-type: proposalGuide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: /images/
+
+*This is just a draft for now...still a work in progress*
+
+This is an informational overview of the life of a podling, from proposal to graduation.
+
+It is intended for people considering incubating their project at the ASF, or people joining podlings,
+as a single page that gives an overview of the incubation process, without going into too much detail.
+
+Links to examples of proposals, discussions etc. are provided
+to give a more concrete overview of what happens during incubation.
+
+We won't include many details - the goal is to keep this short,
+so that you consume it in about ten minutes.
+
+== Proposal
+
+The first step towards incubation is to create a proposal for the Incubator.
+Examples like the link:http://wiki.apache.org/incubator/ClerezzaProposal[Clerezza] and
+link:http://wiki.apache.org/incubator/FlexProposal[Flex] proposals will
+give you a feel for what to put in there.
+
+Creating the proposal will usually raise a number of questions about your future
+podling, and it's good to already find an ASF link:http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion[champion]
+at this stage,
+to answer any questions that you might have or make the necessary contacts.
+
+Once your proposal is ready and you have decided to go forward, you can add it
+to the link:http://wiki.apache.org/incubator/[wiki] and send a [PROPOSAL]
+message to the general@a.o list. Incubator PMC members can then give their feedback
+to help refine the proposal before voting upon it.
+See the link:http://markmail.org/message/5udhowlggdmjsmd6[Flex discussion] for an example.
+
+== Mentors and initial committers
+In general 2-3 incubation mentors, either ASF members of Incubator PMC members
+Need to decide how to manage the list of initial committers
+
+== Incubator entry vote
+Starts when discussion is done
+Point to Flex vote
+72 hours as per ASF voting rules
+Usually driven by the champion
+Usually not contentious, as the previous phases help build consensus
+
+== Podling creation
+Point to Flex jira issues
+Driven by the champion
+
+== Initial code and trademarks
+
+If initial code is being donated you need software grants
+If the donated code has multiple owners or contributors, you might need to chase them down at this point, or omit the code for which you cannot get permission
+Any relevant trademarks should be donated at this point
+
+== First release
+
+It's good to make a first release early, even if it's not of great technical quality.
+From the Incubator's point of view, the release only has to fulfill the ASF's release requirements, which are primarily legal.
+Whether the product is good or useful software doesn't matter at this stage.
+
+Learning the ASF's legal rules and customs, adapting the codebase to conform to them, and getting that first release past the Incubator PMC voting stage can be hard, so it's a good idea to tackle this task during the initial burst of energy as incubation begins.
+A secondary goal of making an early release is to document the podling's release process (link to Flex or Sling process), so that subsequent releases are easy and fast and people who are not core developers may serve as release managers.
+
+== Community growth
+
+To graduate, a podling has to demonstrate its ability to grow its community. In practice, this means attracting and electing new committers and PPMC members.
+Starting early on this helps. (TODO: reading list, Jukka's posts?)
+
+TODO: demonstrate openness/diversity
+
+== Exit discussions
+Incubation can proceed in unexpected directions - the standard exit is to become a TLP but that's not the only possibility (join a TLP, go elsewhere, retire, ...) - which are not necessarily failures.
+
+Discuss with the mentors and community based on the graduation criteria (link - Clerezza discussion?)
+== Graduation vote
+
+If graduating to TLP, First step is to create the board resolution, discuss who's on the new PMC (link to flex as one example),
+it's good to have at least one ASF member in there.
+Community votes first, then IPMC.
+Point to policy + example votes
+
+== Board resolution
+The Incubator PMC acceptance vote is only a recommendation for the board to accept the new project.
+The new TLP only exists once the board approves the resolution to establish it. This is usually announced right after the board meeting, and the new PMC chair
+can then start the mechanics of establishing the TLP.
+
+== Champagne!
+Congratulations - at this point the new TLP is a full blown Apache project, and the newly created PMC is fully in charge of its destiny.
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/policy/roles_and_responsibilities.ad
----------------------------------------------------------------------
diff --git a/pages/policy/roles_and_responsibilities.ad b/pages/policy/roles_and_responsibilities.ad
index 9e9644a..a109c27 100644
--- a/pages/policy/roles_and_responsibilities.ad
+++ b/pages/policy/roles_and_responsibilities.ad
@@ -32,7 +32,7 @@ See also: link:http://www.apache.org/foundation/how-it-works.html#management[How
== Incubator Project Management Committee (IPMC)
-The Incubator PMC [link:/official/resolution.html[resolution]] is responsible for:
+The Incubator PMC [link:https://whimsy.apache.org/board/minutes/Incubator.html#minutes_2002_10_16[resolution]] is responsible for:
* acceptance and oversight of candidate projects submitted or proposed to become part of the Foundation;
* providing guidance and ensuring that sub-projects under it's purview develop products according to the Foundation's philosophy and guidelines for collaborative development;
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/whoweare.ad
----------------------------------------------------------------------
diff --git a/pages/whoweare.ad b/pages/whoweare.ad
new file mode 100644
index 0000000..679e913
--- /dev/null
+++ b/pages/whoweare.ad
@@ -0,0 +1,44 @@
+= Who We Are
+Apache Incubator PMC
+2002-10-16
+:jbake-type: simplepage
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: /images/
+
+[NOTE]
+====
+We ask that you please do not send us emails privately asking for
+support. We are non-paid volunteers who help out with the project and
+we do not necessarily have the time or energy to help people on an
+individual basis. Instead, we have setup mailing lists which often
+contain hundreds of individuals who will help answer detailed
+requests for help. The benefit of using mailing lists over private
+communication is that it is a shared resource where others can also
+learn from common mistakes and as a community we all grow together.
+====
+
+== The Incubator Project Management Commitee (PMC)
+The Incubator PMC is responsible to the link:http://www.apache.org/foundation/board/[Board]
+for the management of the Incubator Project. Only votes cast by members of the incubator PMC
+are binding upon Apache. The work that this project is charged with overseeing differs from
+other projects and so functions a little differently.
+For more details read the link:/guides/pmc.html[Incubator PMC guide].
+
+The list of Incubator PMC members can be found at link:http://people.apache.org/phonebook.html?pmc=incubator[people.apache.org].
+
+== Mentors
+
+Each podling status page lists its mentors. Please see the link:/projects/index.html[summary of Incubator projects].
+
+== Incubator Committers
+
+Each podling status page lists its committers.
+Please see the link:/projects/index.html[summary of Incubator projects].
+
+The list of all Incubator committers can be found on
+link:https://people.apache.org/phonebook.html?unix=incubator[people.apache.org].
+
+There is also a
+link:http://people.apache.org/committer-index.html[list of all Apache committers].
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/templates/menu.gsp
----------------------------------------------------------------------
diff --git a/templates/menu.gsp b/templates/menu.gsp
index a83bffd..d5dbe01 100644
--- a/templates/menu.gsp
+++ b/templates/menu.gsp
@@ -8,7 +8,7 @@
- Apache Incubator
+ Apache Incubator