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 8A219200CC0 for ; Sat, 24 Jun 2017 13:32:12 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 88BE4160BDA; Sat, 24 Jun 2017 11:32:12 +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 5A521160BF3 for ; Sat, 24 Jun 2017 13:32:10 +0200 (CEST) Received: (qmail 16357 invoked by uid 500); 24 Jun 2017 11:32:09 -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 16335 invoked by uid 99); 24 Jun 2017 11:32:09 -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:09 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 4AA33DFA28; Sat, 24 Jun 2017 11:32:07 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: johndament@apache.org To: cvs@incubator.apache.org Date: Sat, 24 Jun 2017 11:32:09 -0000 Message-Id: <403cfad6945a41a5b49a1eceee2cca67@git.apache.org> In-Reply-To: <679d5320430047c7bd20e766cb2b9722@git.apache.org> References: <679d5320430047c7bd20e766cb2b9722@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [3/3] incubator git commit: Continued converting pages to new layout and technology. archived-at: Sat, 24 Jun 2017 11:32:12 -0000 Continued converting pages to new layout and technology. Project: http://git-wip-us.apache.org/repos/asf/incubator/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator/commit/e258a499 Tree: http://git-wip-us.apache.org/repos/asf/incubator/tree/e258a499 Diff: http://git-wip-us.apache.org/repos/asf/incubator/diff/e258a499 Branch: refs/heads/jbake-site Commit: e258a499f838c2f245c8551c2c2938853012ed1c Parents: 64a97b9 Author: John D. Ament Authored: Sat Jun 24 07:32:00 2017 -0400 Committer: John D. Ament Committed: Sat Jun 24 07:32:00 2017 -0400 ---------------------------------------------------------------------- jbake.properties | 3 + pages/faq.ad | 157 ++++ pages/guides/chair.ad | 2 +- pages/guides/lists.ad | 2 +- pages/guides/mentor.ad | 841 ++++++++++++++++++ pages/guides/mentor.xml | 290 ------- pages/guides/names.ad | 266 ++++++ pages/guides/names.xml | 366 -------- pages/guides/participation.ad | 2 +- pages/guides/pmc.ad | 2 +- pages/guides/podling_bootstrap.ad | 334 -------- pages/guides/proposal.ad | 893 +++++++++++++++++++ pages/guides/proposal.xml | 1045 ----------------------- pages/guides/retirement.ad | 4 +- pages/guides/website.ad | 2 +- pages/history/history-timeplot.js | 58 ++ pages/history/index.html | 16 + pages/podling-story.ad | 95 +++ pages/policy/roles_and_responsibilities.ad | 2 +- pages/whoweare.ad | 44 + templates/menu.gsp | 21 +- templates/simplepage.gsp | 11 + 22 files changed, 2411 insertions(+), 2045 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/jbake.properties ---------------------------------------------------------------------- diff --git a/jbake.properties b/jbake.properties index 7f4994b..91a0da5 100644 --- a/jbake.properties +++ b/jbake.properties @@ -3,6 +3,7 @@ site.host=https://incubator.apache.org/ngtest render.tags=false render.sitemap=true template.homepage.file=homepage.gsp +template.simplepage.file=simplepage.gsp template.archive.file=archive.gsp template.tag.file=tags.gsp template.sitemap.file=sitemap.gsp @@ -10,6 +11,8 @@ template.post.file=post.gsp template.page.file=page.gsp template.feed.file=feed.gsp template.guide.file=guide.gsp +template.proposalGuide.file=guide.gsp +template.pmcGuide.file=guide.gsp template.policy.file=policy.gsp render.index=false index.file=index.html http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/faq.ad ---------------------------------------------------------------------- diff --git a/pages/faq.ad b/pages/faq.ad new file mode 100644 index 0000000..0b1d19f --- /dev/null +++ b/pages/faq.ad @@ -0,0 +1,157 @@ += Frequently Asked Questions +Apache Incubator PMC +2002-10-16 +:jbake-type: simplepage +:jbake-status: published +:idprefix: +:toc: +:imagesdir: /images/ + +== Questions + +=== 1. Incubation + +==== 1.1. Does the X Project really have to go in the Incubator to get to Apache? +Yes. +Code that has existed outside the ASF can *only* +enter the ASF through the Incubator. There is no other option. +The Incubator, among other things, is where the due-diligence of +making sure the licence is correct, the link:http://www.apache.org/licenses/#grants[copyright license] +is received, and all of the initial developers submit their link:http://www.apache.org/licenses/#clas[CLAs]. +The Incubator is also the place where projects can familiarize +themselves with how the ASF works under the guidance of Incubator +PMC members (link:incubation/Roles_and_Responsibilities.html#Mentors[mentors]). + +==== 1.2. I'm the mentor of this project, and I think that I'm able to do it by myself. The Incubator doesn't add anything, can it be skipped? + +No. +Do it right, do it well, and add something in the process. +Incubation is not about handing it over to some other group and +seeing what happens. The Incubator is simply the name of the place +that governs your actions when you process a new project into +Apache. It moves at the same rate you do, and achieves whatever +you achieve -- the only difference is that we have a permanent +record in one place that we can go back to if +there are later IP problems, and there is a gate that must be +passed through before the project is given the right to release +software on behalf of the ASF. +That gate will not be ignored or bypassed just because one +group or another feels they have earned the right to bypass it; +allowing that kind of exception destroys the potential to build a +tradition of effective oversight, which is the reason we created +the incubator. + +==== 1.3. Project XXX makes no mention of the Incubator for accepting new projects, but the Incubator site says that all projects entering Apache must pass the Incubator. What do we need to do, to move to the Apache XXX project? + +The incubation process, WRT responsibilities, is roughly as +follows: +- Any Apache PMC (project management commitee), including the +Incubator PMC itself, will approve the entrance of a project +at Apache. They are the link:incubation/Roles_and_Responsibilities.html#Sponsor[Sponsor]. (In rare cases, the Apache Board of Directors +will approve the entrance of a project.) +- The Incubator PMC is from that moment on responsible for the +project. The assigned link:incubation/Roles_and_Responsibilities.html#Mentors[Mentors] (an ASF member who has volunteered to help with +the incubation process) will have the primary responsibility +for overseeing the progress of the project. Each quarter, the +project will submit an update to the entire Incubator PMC as +to the progress in Incubation. +- This will remain so until the Incubator PMC approves the +project to be "graduated". After graduation, if another +PMC sponsored the podling, it will then be transferred to +the PMC that asked for incubation. If the PMC was the +Incubator itself or the Board, the project must then also be +be approved by the Board to receive its own PMC. +- At this point, Incubation is complete. + +So, since you would like to have a place under the XXX Project, +ask that PMC to sponsor you. After that vote, you will +automatically be under the Incubator, and incubation will +start. + +==== 1.4. Someone has proposed that their code/project be donated +to project X within the ASF for continued development. What +do we need to do to accept the code? +The Incubator will only accept code for incubation if a PMC +has voted to accept it. So when a proposal for the donation of +code occurs, the project in question should discuss the proposal +(usually on their public mailing lists!), leading to a decision +by that project's PMC on whether or not to sponsor the code (and +potentially the project surrounding it). +If the PMC agrees, then the incubator can be approached, and the +code accepted for incubation. The grant needs to be recorded by +following the procedure outlined at the link:/ip-clearance/[IP Clearance forms]. + +==== 1.5. The code came from outside the ASF, so it's ours to do as we like, right? + +Wrong. +Here are some generally agreed points that you should take +into consideration: +- No codebase within the ASF is to be considered an exclusive +location for a general technology within the ASF. +- All initial codebases are just that: initial. Once the code is +here, if people feel that the code sucks or the architecture +sucks, or whatever else someone wants to complain about, +all parties understand that the future direction of the +architecture and code is, as is everything at the ASF, +subject to communal will. +- Other contributors interested in any ASF codebase, with or +without existing codebases, are free to contribute, or to +propose additional related projects. + +=== 2. Participation + +==== 2.1. How can I update the site? +Refer to link:guides/website.html[our guide to updating the website]. +If you are not a committer on the Incubator project, +then you can still send patches for the source documents. +==== 2.2. How do I update the incubation status of a project? + +See link:guides/mentor.html#Overview[notes] +about maintaining your project entry in the podlings summary file +and your project status page. + + +==== 2.3. Why don't we use an issue tracking system to track incubation process? + +Issue trackers do not meet the long-term archival and tracking +requirements for our legal purposes and they do not authenticate +that the person entering the status information has the authority +to do so, which is what we get with our version control system. +Note that how the actual day to day tracking of the project (i.e. +bugs in code) is done is not the same as filing the legal forms - +for those issues, our normal issue trackers can be used. +Nevertheless, SVN is our only authoritative and formal tracking +system for incubation status. + +==== 2.4. How do I update the site of an incubating project? +First of all, read our link:/policy/incubation.html[Incubation Policy]. +Refer to the link:guides/sites.html[Website Guide]. + +==== 2.5 How Do I Obtain Karma For The Infrastructure Site? + +All requests for karma (whether for a podling web site or for the infrastructure site itself) +should be directed to the incubator general list. + +Please read the link:&root-path;/guides/website.html[website guide] before editing the website. + +==== 2.6 How Do I Set Up The Podling Website? + +To set up the website for a podling, start by requesting link:#site-karma[karma]. + +==== 2.7 How Do I Grant Karma To An Existing Apache Committer? + +This link:http://apache.org/dev/pmc.html#karma[document] describes how to grant karma for an +existing Apache committer. + +==== 2.8 What are the various facilities that assist with Incubator management, and how are they generated and maintained? + +See link:facilities.html[Facilities for Incubator management]. + +=== 3 Infrastructure + +==== 3.1 How does our project request resources? + +Co-ordinate via your project's dev list and PPMC. Often someone +there will know what is necessary. +Some notes are provided in the +link:guides/mentor.html#request-required-resources[Mentor guide] and in the link:http://www.apache.org/dev/infra-contact[Infrastructure instructions]. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/chair.ad ---------------------------------------------------------------------- diff --git a/pages/guides/chair.ad b/pages/guides/chair.ad index f422e60..f17392f 100644 --- a/pages/guides/chair.ad +++ b/pages/guides/chair.ad @@ -12,7 +12,7 @@ = Incubator Chair Guide 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/guides/lists.ad ---------------------------------------------------------------------- diff --git a/pages/guides/lists.ad b/pages/guides/lists.ad index 26346c8..b277ee7 100644 --- a/pages/guides/lists.ad +++ b/pages/guides/lists.ad @@ -12,7 +12,7 @@ = Incubator Mailing Lists Guide 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/guides/mentor.ad ---------------------------------------------------------------------- diff --git a/pages/guides/mentor.ad b/pages/guides/mentor.ad new file mode 100644 index 0000000..0298883 --- /dev/null +++ b/pages/guides/mentor.ad @@ -0,0 +1,841 @@ +//Licensed under the Apache License, Version 2.0 (the "License"); +//you may not use this file except in compliance with the License. +//You may obtain a copy of the License at +// +//http://www.apache.org/licenses/LICENSE-2.0 +// +//Unless required by applicable law or agreed to in writing, software +//distributed under the License is distributed on an "AS IS" BASIS, +//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +//See the License for the specific language governing permissions and +//limitations under the License. += Mentors' Guide +Apache Incubator PMC +2002-10-16 +:jbake-type: pmcGuide +:jbake-status: draft +:idprefix: +:toc: +:imagesdir: ../images/ + +The Mentors' guide is a go-to place for information about getting a podling up and running from an infrastructure point of view. + + + + + +general@incubator.apache.org Archives +Projects + + +
+Mentor Guide +

This document targets any Incubating Project member, but +especially Mentors, who have to ensure that some things get done. +For a general description of the role of a mentor on an incubating +project see the +Roles and Responsibilities +document. +

+This guide is a descriptive and at times +discursive document. It describes established practices. +It is informational not normative. Policy is laid down in the +Incubation Policy. +

+
Contents
+
+
+Overview +

+After the Podling has been accepted by the Incubator PMC, one of the mentors +sets up +the Podling; i.e. adds the podling metadata, creates the initial Podling status page, and +either creates or requests that +other resources (mail lists, subversion, bug tracker, etc.) +be created. +

+
+
+Add to Incubation Summary file +

+Add the podling to the podling summary file in +the "incubator" SVN at content/podlings.xml +(e.g. copy the entry from another podling that also has status="current") +and see instructions. +

+

+Please do this step ASAP after Acceptance. Other setup procedures utilize +this metadata. +

+

+Add a 'reporting' tag (after 'description') with the attribute 'monthly="true"' +and the appropriate "group" attribute, based on the month in which the podling +entered incubation (1 for January, April, July, October, 2 for February, May, +August, November or 3 for March, June, September, December). The text content +of the 'reporting' tag must contain the initial list of reporting months, +starting with the month after the podling entered incubation. For example: +<reporting group="2" monthly="true">June, July, August</reporting> +Once the first three reports are complete, the monthly attribute should be removed +and the list of months removed as well. +

+

+The first report might be +very short. However it is better that the Incubator PMC can help to +guide through the early setup stages. +For more details see the +PPMC Guide. +

+
+
+Initialize Podling Status Page +

+A mentor needs to +create the +web page that will track the project's status. +A mentor will also need to update it until +others in the +the project's PPMC can update it. +

+The status +page is the incubator's record of the progress made. +It MUST be kept update to date during incubation. +Some of the information is available from the proposal. +As the startup process continues and resources are +created the status SHOULD be updated. +

+The template contains lists of actions which may be needed +to start up a podling. All those which do not apply should +be deleted. +

+The status page is a useful aid to workflow. Volunteers +can use it to sign up to the various tasks and monitor their +progress. Once the mailing lists are set up and prospective +committers subscribe then these may be used for discussion. +

+
+
Request Required Resources +

+The proposal should include a list of required resources. All of these will +require active set up. Some are created by infrastructure after an appropriate +request, others can be set up by any IPMC members (typically mentors). +

+Mailing lists should be created first. Other resources typically +post information to these lists. +

+
Request Mailing Lists +

+Apache mailing lists require volunteer moderators. New moderators can be +changed later +but at least one volunteer is required before the mailing lists can be set up. +Moderation is a reasonably +easy task +though moderators may want to set up +spam filtering. +Having at least three moderators is recommended to spread the load. +

+The proposal should contain the rest of the information that needs to be collected +before the mailing lists can be requested. Incubator is the responsible top level project. +So the domain MUST be incubator.apache.org. +For example: +

+
    +
  • dev@${podling}.incubator.apache.org
    • +
  • commits@${podling}.incubator.apache.org
    • +
  • private@${podling}.incubator.apache.org
    • +
+

+For initial community building it is usually appropriate to only have +a "dev" list, to keep the discussions focussed. Later add a "user" list +if needed. +

+ +Commits under http://svn.apache.org/repos/asf/incubator/${podling} +will be emailed to commits@${podling}.incubator.apache.org. +Any deviation will +require special configuration in the asf-mailer.conf file by the IPMC. + +

+Mailing lists creation is a task for the infrastructure team. The +infrastructure team offers a tool that simplifies the creation of mailing lists. You can access the +Incubator Mailing List Request Form +to request a list. A notification will be sent to private@incubator when the lists have been created. +

+

+Remember to update the project status file with mailing list details. Prospective committers +and mentors will need to subscribe. Email them once the status file has been updated. Inform +any existing mailing lists or forums previously used by the project. +

+

+Once the commits list is created, the project MUST review +the /incubator/${podling} tree, since any commits made prior +to the list's creation will have generated no email trail. +

+
Mail Archives +

+Archives at http://mail-archives.apache.org for the public +mailing lists will be setup as part of the mailing list creation process. No action is +required by Mentors. The archives will be visible +as soon as posts have been made (and moderated) to these lists. +

+

+You can also leverage lists.apache.org for +mailing list archives. There is a login link in the top right corner, which allows you to respond to +threads from within the web application. +

+

+Many projects are independently archived externally (for example, at +The Mail Archive and +MARC) +Independent archives help to +increase project visibility as well as preserving a independent historic record. +These subscriptions are not automatically created. If desired, subscribe manually. +

+Subscriptions to news-to-mailing-list bridges (for example, Nabble) +must also be created manually. Subscribing helps accessibility and visibility but Nabble news +users may not be aware that they are posting to a mailing list. +

+
+
Mailing List Administration +

+Apache uses ezmlm. See the +manual and +committer mail FAQ +for more details. +

+
+
Mailing List Transition +

+Independent mailing lists and groups are perfectly acceptable but development should +happen on the official mailing lists at Apache. If a project has existing mailing lists, +forums or groups the community needs to consider their future and plan for the transition +to the official Apache mailing lists. +

+It may be useful to move development first to the official lists followed gradually +by the user resources. +

+

+Note that subscribers of external mailing lists will not be automatically subscribed +to the new Incubator project mailing lists. Instead, a note should be posted to the +old external mailing list asking them to subscribe to the new list. If possible, add +a footer to the old mailing list with some instructions. +

+
+
Issue Tracking +

+If any Mentor has project-creation karma (in the issue tracking system to be used) +then they should execute. +If no Mentor has the required karma then file an INFRA issue using the 'new jira project' +type (not bug or request) +

+

+Remember to post an email announcing that the issue tracker is available. +

+
+
+ +
+Set Up Podling Source Repository + +

+The most important responsibility for mentors is to set up the +podling source repository. Podlings can choose between svn and +git for source control. +

+ +
+Set up GIT Repository +

+Requests for new git repos are done via reporeq.apache.org. +This service will initialize a new repository, setup github mirrors and enable integrations for that repository. +

+

+The Foundation's policy +is to grant access to git repositories broadly to the incubator group, +not narrowly podling-by-podling. So, once the repository +exists, incubator group members gain access without further work. Once +the podling graduates, a dedicated ldap group will be created to manage +access and only those members will be given access. +

+
+
+Set Up SVN Repository +

+If the podling chooses svn, you must create the +repository and give read/write access to the repository +to all the committers for the podling. This involves requesting +new committer accounts and granting access to mentors and existing +Apache committers. +

+

Setting up a podling subversion repository has two steps: Creating the SVN space +and configuring the authorization (in both svn and git). +

+

+Create the workspace in svn. This requires commit access to the +incubator svn repository. Podlings are given their own subdirectory +of the incubator svn repository. To create the podling subdirectory, +the mentor executes the svn command to create a remote directory: + +svn mkdir https://svn.apache.org/repos/asf/incubator/{podling} + +

+

Create the workspace authorization in asf-authorization-template. +This requires commit access to infrastructure-puppet to modify the file +https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob;f=modules/subversion_server/files/authorization/asf-authorization-template. +Please follow the procedures in the infrastructure puppet workflow document. +

+

+Edit the file to add the podling repository in alphabetical order, e.g. +

+{podling}={mentor1},{mentor2} +

+In the section listing all the projects (again in alphabetical order) +add the podling directory and permissions, to enable the podling for its +eventual website: +


+[/incubator/{podling}] +@{podling} = rw +... +

+

+
+

+This is a convenient time to add authorization for committers +who have accounts. +

+

+Authorization karma is restricted. If no Mentor +has this karma then post an email to IPMC private list requesting that this +is actioned. +

+
+
+Authorize Committers +

The process to add committers to the podling depends on whether +the new committer is already an Apache committer and whether +the new committer is in the list of original committers: +

+
    +
  • The committer is in the list of original committers in the +podling proposal to the incubator and is not already an Apache +committer: +
      +
    • +Ask developers to send their ICLA to secretary@apache.org according to +standard procedure. +Note that ICLA forms must be signed, either by hand or by digital signature. +
      • +
    • +Developers should choose an Apache id that is not already listed +here. +
      • +
    • +Developers should enter their preferred Apache id on the ICLA +and enter the podling name in the "notify" field of the ICLA. +
      • +
    +
    • +
  • The committer is in the list of original committers in the +podling proposal to the incubator and is already an Apache committer, only +incubator authorization is required. +
    • +
  • The committer was voted by the PPMC and approved by the incubator +PMC: +
    • +

    +Perform one of the above procedures depending on whether the +committer is already an Apache committer on another project. +

    +
+
+
+ +
[DRAFT] Podling Bootstrap +

+NOTE This section is a DRAFT under development. +

+

+Following podling creation, it needs to be bootstrapped. Here are some of +the tasks: +

+
    +
  1. Ensure Mentors are on the IPMC[Mentors]
    2. +
  2. Add podling to reporting schedule [IPMC member]
    3. +
  3. Initialize project status page [IPMC member]
    4. +
  4. Start orientation [Prospective committers]
    5. +
  5. Start CLA and CCLA submission [Prospective committers]
    6. +
  6. Start IP Clearance +[IPMC member]
    7. +
  7. Request Required Resources +
      +
    1. Mailing Lists [Infrastructure Team] + +
      2. +
    2. Subversion [IPMC]
      3. +
    3. Issue Tracking [Infrastructure Team] + +
      4. +
    +
    8. +
  8. Create website [Prospective committers] +
      +
    1. Consider and plan web site transition
      2. +
    +
    9. + +
+
Mentors MUST be on the IPMC +

+Mentors MUST be on the IPMC. +Any prospective Mentors who are not yet on the IPMC should ask to be added (by election). +Email the application to private@incubator.apache.org. +

+ +This process may take a few days. + +
+ +
CLA and CCLA Submission +

+Prospective committers need to submit a +Contributor License Agreement +(CLA). +This process can take a while so it is recommended that committers start to submit +these as soon as the podling is accepted. +

+
+ +
IP Clearance +
Background +

+Existing codebases need to be imported through the standard IP clearance +process. This means that a Software Grant Agreement +(SGA) +or Contributor License Agreement +(CLA) +need to be submitted +for all copyright owners. This process may take a while so it is best to +start as soon as the podling is accepted. +

+

+The acceptance of the initial codebases is approved by the +IPMC as part of the acceptance motion. So, no vote is required by the +PPMC. Otherwise, follow the standard IP clearance +process for podlings. +

+
+
Establishing Provenance +

+Paperwork needs to be submitted to Apache that grants a legal license on the code +to the Apache Software Foundation. +As a rule of thumb, if all the material contributors to the code +are joining the podling as initial contributors, then CLAs (individual or corporate) +are all you need. The individuals must submit the 'individual' CLA (ICLA). +If there are employers involved who might claim +rights in the code, then corporate CLAs (CCLAs) are needed for those employers. +

+If, on the other hand, there are material contributors who are +not joining the podling as initial contributors, or if there +are additional corporate entities who can claim rights in the code, +then SGAs are required from those individuals or corporations. +

+

+The foregoing is only a rule of thumb. Generally, the mentors of a new project +will need to consult with general@incubator.apache.org or the Apache legal team +about the particular circumstances. +

+

+It may take some time to track down all contributors. It is not necessary to +have paperwork on file for all contributions before the code is imported. +It may be necessary to reverse some patches and rewrite areas of code if +contributors cannot be found or at not happy about given Apache written +permission to use their code. +

+No releases are possible until the provenance of all the code to be release +has been clearly established and the relevant paperwork filed with Apache. It is +therefore important to keep the status updated. +

+Receipts of ICLAs, CCLAs, and SGAs are recorded by the secretary in +the private foundation repository. Reading is restricted to members and officers +of the foundation. If there is no officer or member available then ask on the +general list. +

+
+
Initial Code Dump +

+For corporate contributions, the SGA or CCLA MUST be completed, submitted +and received before the code is imported. +

+For contributions composed of patches from individual contributors, +it is safe to import the code once the major contributors (by volume) +have completed ICLAs or SGAs. +

+In either case, the code to be imported should be attached to a JIRA +and then imported. It is recommended that the previous version +control system is tagged so that the imported version is precisely known. +

+A public record MUST be made of the code imported. If the import is not +attached to JIRA then it MUST be committed to version control. +

+
Importing History +

+The incoming code can either be committed as a snapshot or as a complete version +control export including history (provided that the import is available in a format +readable by subversion). +Importing with history allows existing open source projects who want to maintain +older versions at Apache to easily perform source diffs and so on. Import just the +latest code allows a clean break to be made with the past. The choice is left to +the community of the incoming project. +

+The infrastructure team will perform the import including +mapping IDs but it is an operation that requires skill, time and care. In this case, +please ask the infrastructure team politely. +

+
+
+
Audit Cryptography +

+Before the code base is committed into an Apache repository, the contribution +MUST be checked +and any restricted cryptography reported appropriately. Read and follow +this guide. +

+
+
+Initial Clean Up +

+Once a JIRA has been created, the source should be cleaned up. +

+

+

    +
  • +Ensure source files use the standard Apache boilerplates. +This may mean replacing existing license headers. The +tools in + +https://svn.apache.org/repos/private/committers/tools + +and + +https://svn.apache.org/repos/private/committers/relicense + +may be useful. +
    • +
  • +Ensure that NOTICE and LICENSE documents are present and +correct +
    • +
  • +Add any required notices. Consider moving copyright +attributions from source documents to the NOTICE. Read + +Apache policy on headers + +. +
    • +
  • +Audit the source for any potential licensing issues. Any +which are found should either resolved immediately (when +required) or noted in the status document for later. +
    • +
+

+

+It is recommended that the initial clean up be is started +before the code is committed. It MUST be completed before any +releases are cut. +

+
+Clean Up Best Practice +

+It is recommended that version control is used to create a +public record of the process. This will assist anyone +auditing the code provenance (now or in the future) to +easily perform due diligence without contacting the people +who performed the clean up. The clean up process should +therefore clearly document (using version control) the +evolution of the IP licensing. +

+

+Particular care needs to be taken with commit messages +during clean up. The intended audience needs to include +lawyers and code auditors. Members of the public need to be +able to follow and understand the process from these +messages alone. +

+

+It is therefore recommended that the initial source is +(after being expanded from the archive) checked in as is +into a special directory ( +${project}/trunk/import +is suggested). The original packaging, copyright statements +and license notices should be preserved. A standard Apache +LICENSE and appropriate NOTICE should be added at the top +for the copyright for the collective work (see + +policy + +). Take particular care with this commit message. As with +any patch that contains code which is not the original work +of the committer, the JIRA url (for the artifact imported) +needs to be included together with notes about the original +copyright owner and any associated paperwork. The fact that +this is a exact import including original headers should be +noted to stop any queries about these foreign headers. +

+

+The cleanup should then proceed in a number of commits. If +the source provenance is complex, break the process up into +a number of logical steps committing each in turn with a +good message. +

+

+In particular, take care when relocating copyright +statements and license notices into the NOTICE in the root +directory: consider moving each copyright owner individually +so that it is easier to audit. (See + +policy + +.) +

+

+Once a section of code has been cleaned up +(and repackaged, +if necessary) normal development can begin. +

+
+
+
On Repackaging +

+It is recommended - but not mandated - that source is repackaged +under the Apache namespace. There is no need to use the incubator +namespace. For example, Java source might be repackaged to +org.apache.foo.Bar or a DTD to http://dtd.apache.org/foo/bar. +

+Existing open source projects moving to Apache may well need to consider +carefully how they will approach this transition. +

+
+
Update Documents +

+Check the documentation for references to the old home of the project and update them +with references to Apache. +

+Read +Branding Guide. +Ensure that appropriate disclaimers are added to the appropriate documentation. +Consider adding a DISCLAIMER text document. +

+
Update Build +

+If the project uses Apache Maven, the pom will +need to be updated to reflect that the project is now at Apache. In particular: +

+
    +
  • Update mailingLists
    • +
  • Update organization
    • +
  • Update url
    • +
  • Update issueManagement
    • +
  • Check licenses
    • +
  • Update scm
    • +
  • Update groupId
    • +
  • Update manifestEntries. It is recommended that the +standard Apache settings are used
    • +
  • Update developers to use apache IDs (when known)
    • +
  • Update distributionManagement
    • +
  • Consider specifying a relocation
    • +
+

+If the project uses Apache Ant, the build script +will probably need to be updated. In particular: +

+
    +
  • Ensure any MANIFESTs generated refer to Apache. It is recommended that the +standard Apache settings are used.
    • +
  • Check that LICENSE, NOTICE and - if appropriate - +DISCLAIMER documents are copied into binary artifacts
    • +
+
+
+
+
Orientating New Committers: Understanding Apache +

+When a committer is elected by a typical top level project, the nominator +and other PMC members educate the new committer about Apache. In the Incubator, this +inductive must be performed by the Mentors. This process is one of the most important +for the long term health of a project. +

+Apache works on the principle that discussions should happen on the most open forum +available. Unless the matter involves a sensitive matter (such as security or +personal issues), it should be raised on an open mailing list (typically the podling dev list +or the incubator general list). Use of the incubator private list should be reserved +for official notifications and sensitive topics. +

+Mentors need to take care. During the initial bootstrapping a habit may develop +of emailing private list. It is important to break this habit as soon as the mailing +lists are available. +

+Netiquette about the correct use of cc's may also be difficult to +effectively impart. During the bootstrap process there are a number of occasions +where cc's are required. The typical usage is to copy in a private +listing to indicate that the action has the lazy permission of the committee. +cc's are very commonly used to create inefficient ad-hoc mailing lists in +the commercial world. Except for a small number of defined processes, cc's +are frowned upon at Apache. Mentor need to encourage questions to be asked first +on the public lists of the project then raised (if necessary) to the general +incubator list. +

+TODO: content, links, prose, reconsider name for this section +

+
+ +
Issue Tracking Transition +

+Issues for Apache projects should be tracked on Apache hardware. Some projects arrive +with existing issues tracking. So, in the end these need to be replaced (for new development +at least) by the Apache issues tracker. Options need to be discussed publically on list +and a consensus reached about the best transition strategy. +

+
+
+ +
Podling IP Clearance +

+The board has charged the Incubator project with management of IP clearance for Apache. +Instructions are here. +

+These equally apply to podlings. The Incubator project is responsible for all podlings +and so is the receiving PMC. So, when a podling requests IP clearance, the +IPMC wears two hats. +This may be a little confusing at first. +

+The Incubator PMC must approve the clearance. This indicates that the project is +happy to receive the code donated. When a new podling is created, this is done +by the identification of existing codebases in the proposal. Otherwise, the +IPMC delegates this decision to the PPMC. +

+As usual, three binding votes are required. So, Mentors need to be involved in +IP clearance for podlings. If too few binding VOTEs are posted on list, +the VOTE will need to be posted to the general list for ratification. +

+The second hat is technical IP clearance. Here, the IPMC needs to check that the +paperwork is in order. Once the acceptance vote has been approved, an officer +or member need to complete the process. For a podling, this will typically +involve a Mentor. +

+
+ +
Create Initial Website +

+Podlings are free to use any technology desired to generate static content to be +served under http://${podling-name}.incubator.apache.org/. +However, the infrastructure team has some requirements for the publication +process to manage the load on servers. The page linked below on the Apache CMS +has more information. +

+

+Some popular choices are: +

+ +

+It is recommended that an initial site is uploaded as soon as possible (to - +for example - allow indexing by search engines). The initial site +can be replaced by a fuller site later. +Read the +Podling Website Guide +for more information. +

+ +Apache Infrastructure does not guarantee that site content stored only on the www server +will be fully backed up in the event of failure. Consider checking the site into +version control if it needs to be comprehensively backed up. + +

+Projects with an existing website who move to Apache need to consider +what they plan to do with it. A decision should be reached and action upon before +graduation. +

+ +
Web Site Transition +

+Projects may arrive with existing web sites outside Apache. Contributing as much +documentation as possible to the project from these sites is strongly encouraged. +Offshore sites related to projects are fine but official web sites for Apache +projects should be hosted by Apache. +

+Some projects elect to maintain previous releases outside Apache. In this case, the existing site +is typically retained as a hub for this maintenance work. Otherwise, sites should link +or redirect to the official Apache site. +

+Apache may accept donations of domains related to projects moving here. +Infrastructure will then arrange for renewal of the domains and redirection +of traffic the official site. Ask infrastructure for more details. +

+Apache needs to deal with all commercial entities equitably. Linking to +useful information on commercial sites is fine but unfair discrimination between +commercial sites is not. Most Apache projects find it better to simply link only +to relevant articles on commercial sites rather than having to vet every request +for links to commercial activity. +

+
+
+
+
Glossary +
Prospective Committers +

+These are the people listed as initial committers in the proposal. +

+
+ +
Infrastructure Team +

+Tasks that cannot safely be delegated to projects are handled by the Apache +Infrastructure team. +The relevant instructions +MUST be followed. +JIRA is typically used to +manage workflow. This allows progress to be easily tracked. +

+
+
Incubator Access Authorization +

+Special karma is required to authorize incubator access for committers. +This karma is limited to: +

+
    +
  • PMC Chairs (past and present)
    • +
  • Selected people in the Infrastructure team
    • +
+

+If any mentor has karma then they should authorize the committer. +To grant authorization, update: +

+ +infrastructure/trunk/subversion/authorization/asf-authorization-template + +

+Edit the file to add the new committer to the podling authorization: +

+ +{podling}={mentor1},{mentor2},{new-committer} + +

+If no mentor has karma then an email should be posted to the IPMC private +list requesting that the grant is performed. One of the IPMCers with karma +will authorize the committer. +

+
+
+ + + http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/mentor.xml ---------------------------------------------------------------------- diff --git a/pages/guides/mentor.xml b/pages/guides/mentor.xml deleted file mode 100644 index d4f493f..0000000 --- a/pages/guides/mentor.xml +++ /dev/null @@ -1,290 +0,0 @@ - - - - -]> - - - - general@incubator.apache.org Archives - Projects - - -
- Mentor Guide -

This document targets any Incubating Project member, but - especially Mentors, who have to ensure that some things get done. - For a general description of the role of a mentor on an incubating - project see the - Roles and Responsibilities -document. -

- This guide is a descriptive and at times -discursive document. It describes established practices. -It is informational not normative. Policy is laid down in the -Incubation Policy. -

-
Contents
-
-
- Overview -

- After the Podling has been accepted by the Incubator PMC, one of the mentors - sets up - the Podling; i.e. adds the podling metadata, creates the initial Podling status page, and - either creates or requests that - other resources (mail lists, subversion, bug tracker, etc.) - be created. -

-
-
- Add to Incubation Summary file -

- Add the podling to the podling summary file in - the "incubator" SVN at content/podlings.xml - (e.g. copy the entry from another podling that also has status="current") - and see instructions. -

-

- Please do this step ASAP after Acceptance. Other setup procedures utilize - this metadata. -

-

- Add a 'reporting' tag (after 'description') with the attribute 'monthly="true"' - and the appropriate "group" attribute, based on the month in which the podling - entered incubation (1 for January, April, July, October, 2 for February, May, - August, November or 3 for March, June, September, December). The text content - of the 'reporting' tag must contain the initial list of reporting months, - starting with the month after the podling entered incubation. For example: - <reporting group="2" monthly="true">June, July, August</reporting> - Once the first three reports are complete, the monthly attribute should be removed - and the list of months removed as well. -

-

- The first report might be - very short. However it is better that the Incubator PMC can help to - guide through the early setup stages. - For more details see the - PPMC Guide. -

-
-
- Initialize Podling Status Page -

- A mentor needs to - create the - web page that will track the project's status. - A mentor will also need to update it until - others in the - the project's PPMC can update it. -

- The status - page is the incubator's record of the progress made. - It MUST be kept update to date during incubation. - Some of the information is available from the proposal. - As the startup process continues and resources are - created the status SHOULD be updated. -

- The template contains lists of actions which may be needed - to start up a podling. All those which do not apply should - be deleted. -

- The status page is a useful aid to workflow. Volunteers - can use it to sign up to the various tasks and monitor their - progress. Once the mailing lists are set up and prospective - committers subscribe then these may be used for discussion. -

-
-
Request Required Resources -

- The proposal should include a list of required resources. All of these will - require active set up. Some are created by infrastructure after an appropriate - request, others can be set up by any IPMC members (typically mentors). -

- Mailing lists should be created first. Other resources typically - post information to these lists. -

-
Request Mailing Lists -

- Apache mailing lists require volunteer moderators. New moderators can be - changed later - but at least one volunteer is required before the mailing lists can be set up. - Moderation is a reasonably - easy task - though moderators may want to set up - spam filtering. - Having at least three moderators is recommended to spread the load. -

- The proposal should contain the rest of the information that needs to be collected - before the mailing lists can be requested. Incubator is the responsible top level project. - So the domain MUST be incubator.apache.org. - For example: -

-
    -
  • dev@${podling}.incubator.apache.org
    • -
  • commits@${podling}.incubator.apache.org
    • -
  • private@${podling}.incubator.apache.org
    • -
-

- For initial community building it is usually appropriate to only have - a "dev" list, to keep the discussions focussed. Later add a "user" list - if needed. -

- - Commits under http://svn.apache.org/repos/asf/incubator/${podling} - will be emailed to commits@${podling}.incubator.apache.org. - Any deviation will - require special configuration in the asf-mailer.conf file by the IPMC. - -

- Mailing lists creation is a task for the infrastructure team. The - infrastructure team offers a tool that simplifies the creation of mailing lists. You can access the - Incubator Mailing List Request Form - to request a list. A notification will be sent to private@incubator when the lists have been created. -

-

- Remember to update the project status file with mailing list details. Prospective committers - and mentors will need to subscribe. Email them once the status file has been updated. Inform - any existing mailing lists or forums previously used by the project. -

-

- Once the commits list is created, the project MUST review - the /incubator/${podling} tree, since any commits made prior - to the list's creation will have generated no email trail. -

-
Mail Archives -

- Archives at http://mail-archives.apache.org for the public - mailing lists will be setup as part of the mailing list creation process. No action is - required by Mentors. The archives will be visible - as soon as posts have been made (and moderated) to these lists. -

-

- You can also leverage lists.apache.org for - mailing list archives. There is a login link in the top right corner, which allows you to respond to - threads from within the web application. -

-

- Many projects are independently archived externally (for example, at - The Mail Archive and - MARC) - Independent archives help to - increase project visibility as well as preserving a independent historic record. - These subscriptions are not automatically created. If desired, subscribe manually. -

- Subscriptions to news-to-mailing-list bridges (for example, Nabble) - must also be created manually. Subscribing helps accessibility and visibility but Nabble news - users may not be aware that they are posting to a mailing list. -

-
-
Mailing List Administration -

- Apache uses ezmlm. See the - manual and - committer mail FAQ - for more details. -

-
-
Mailing List Transition -

- Independent mailing lists and groups are perfectly acceptable but development should - happen on the official mailing lists at Apache. If a project has existing mailing lists, - forums or groups the community needs to consider their future and plan for the transition - to the official Apache mailing lists. -

- It may be useful to move development first to the official lists followed gradually - by the user resources. -

-

- Note that subscribers of external mailing lists will not be automatically subscribed - to the new Incubator project mailing lists. Instead, a note should be posted to the - old external mailing list asking them to subscribe to the new list. If possible, add - a footer to the old mailing list with some instructions. -

-
-
Issue Tracking -

- If any Mentor has project-creation karma (in the issue tracking system to be used) - then they should execute. - If no Mentor has the required karma then file an INFRA issue using the 'new jira project' - type (not bug or request) -

-

- Remember to post an email announcing that the issue tracker is available. -

-
-
- - -
Glossary -
Prospective Committers -

- These are the people listed as initial committers in the proposal. -

-
- -
Infrastructure Team -

- Tasks that cannot safely be delegated to projects are handled by the Apache - Infrastructure team. - The relevant instructions - MUST be followed. - JIRA is typically used to - manage workflow. This allows progress to be easily tracked. -

-
-
Incubator Access Authorization -

- Special karma is required to authorize incubator access for committers. - This karma is limited to: -

-
    -
  • PMC Chairs (past and present)
    • -
  • Selected people in the Infrastructure team
    • -
-

- If any mentor has karma then they should authorize the committer. - To grant authorization, update: -

- - infrastructure/trunk/subversion/authorization/asf-authorization-template - -

- Edit the file to add the new committer to the podling authorization: -

- - {podling}={mentor1},{mentor2},{new-committer} - -

- If no mentor has karma then an email should be posted to the IPMC private - list requesting that the grant is performed. One of the IPMCers with karma - will authorize the committer. -

-
-
- - - http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/names.ad ---------------------------------------------------------------------- diff --git a/pages/guides/names.ad b/pages/guides/names.ad new file mode 100644 index 0000000..51542b2 --- /dev/null +++ b/pages/guides/names.ad @@ -0,0 +1,266 @@ +//Licensed under the Apache License, Version 2.0 (the "License"); +//you may not use this file except in compliance with the License. +//You may obtain a copy of the License at +// +//http://www.apache.org/licenses/LICENSE-2.0 +// +//Unless required by applicable law or agreed to in writing, software +//distributed under the License is distributed on an "AS IS" BASIS, +//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +//See the License for the specific language governing permissions and +//limitations under the License. += Podling Name Search Guide +Apache Incubator PMC +2002-10-16 +:jbake-type: guide +:jbake-status: published +:idprefix: +:toc: +:imagesdir: ../images/ +== Introduction + +This guide is *not* _legal advice_ or _legal opinion_: +*do not* use it as a substitute. +Its aims are education and information *only*. + +This process filters out unsuitable names early, +reducing the legal resources required and +limiting the potential disruption to a community of a forced name change +later. A smooth path, but not the only one. If there are reasons +why this road isn't right for your podling, +consult link:http://mail-archives.apache.org/mod_mbox/incubator-general/[incubator general]. + +=== Meet The Apache Branding Team + +Names link:http://www.apache.org/foundation/marks/#whoweare[fall] within the responsibilities of the +link:http://www.apache.org/foundation/[V.P., Brand Management] (and +link:http://www.apache.org/foundation/marks/#whoweare[team]). Please start by reading: + +-the link:http://www.apache.org/foundation/marks/' rel='tag[Apache Trademark Policy] (which introduces trademarks and outlines our policy); +-the link:http://www.apache.org/foundation/marks/faq/' rel='tag[Apache Trademark FAQs] (which answers questions asked by downstream consumers); and +-the link:http://www.apache.org/foundation/marks/pmcs.html[Apache Project Branding Requirements] (which guides PMCs). + +For podlings in the Incubator, naming issues are managed co-operatively by the Brand and Incubator communities. +Rules for podlings include all branding requirements for PMCs, plus a few extras. + +=== Trademarks + +Trademark law is a complex subject. +Distinctive differences from other intellectual property laws (such as patent or copyright) mean that +intuition or knowledge gained from other areas may not be applicable. +The link:http://www.apache.org/foundation[Apache Software Foundation] is +a link:http://www.apache.org/foundation/faq.html#is-ASF-a-corporation[US corporation]. +Developing some understanding of the basic principles of US trademark law is therefore important. + +Please read: + +- link:http://www.apache.org/foundation/marks/#principles[Description of key trademark principles] for Apache projects; +- USPTO trademark + - link:http://www.uspto.gov/trademarks/index.jsp[home] page + - link:http://www.uspto.gov/trademarks/basics/index.jsp[basics], and follow the links for materials; +- link:http://en.wikibooks.org/wiki/US_Trademark_Law[US Trademark Law] WikiBook; and +- link:http://www.ifosslr.org/ifosslr/article/view/11/37[Passport Without A Visa: Open Source Software Licensing and Trademarks] by Tiki Dare and Harvey Anderson in the link:http://www.ifosslr.org/[International Free and Open Source Software Law Review]. + +==== Trademarks And The Apache License + +Like link:http://www.ifosslr.org/ifosslr/article/view/11/37[many] +link:http://www.opensource.org[open source] licenses, the +link:http://www.apache.org/licenses/LICENSE-2.0.html[Apache License, Version 2.0] +focuses on granting copyright and patent rights to the public. +The _trademark_ section permits only very limited trademark rights. + +[quote] +"" +*6. Trademarks.* +This License does not grant permission to use the trade names, trademarks, +service marks, or product names of the Licensor, except as required for +reasonable and customary use in describing the origin of the Work and +reproducing the content of the NOTICE file." +"" +-- link:http://www.apache.org/licenses/LICENSE-2.0.html#trademarks[Apache License, Version 2.0] + +All Apache projects share the Apache License. This issues standard *copy* +and *patent* rights to +downstream consumers. *Trademark* rights for Apache products are issued and managed independently, +beyond the Apache License. This allows Apache communities to use trademark law to protect their reputation and that of the +link:http://www.apache.org/foundation/[Foundation], within the broader +framework provided by the Brand team. + +=== What Makes A Name Good +Good names for commercial products or _UNIX_ utilities have tended to work less well here at Apache. +Many successful Apache project names are memorable, unusual and a little +link:http://www.sdtimes.com/TOP_FIVE_HEAD_SCRATCHINGEST_NAMES_FOR_APACHE_PROJECTS/By_Victoria_Reitano/About_APACHE_and_HADOOP_and_HARMONY_and_MYSQL_and_OODT_and_YAY/35959[whimsical]. +These qualities also happen to be useful when it comes to securing trademark protection. +Have fun. Be creative. + +=== Podling Suitable Name Search + +The initial link:http://incubator.apache.org/guides/proposal.html[proposal] +establishes a working name for the new podling. +Often some discussion and filtering of suitable names happens during the election +process but this proposed name is *not* final, only _provisional_. +The community may choose to change it. Or the community may discover that the name is unsuitable: +in which case a suitable new name must be found. + +A podling needs to discover whether a name is suitable. +The Incubator community calls this process the _suitable name search_. +This avoids any potential confusion with phrases like +_trademark search_ with technical meanings in the trademark community. +Please be careful with language. In particular: + +- avoid using loaded technical legal terms; +- use plain, simple English to describe what you did and what you found; +- avoid speculation; and +- don't offer _advice_ or _opinions_. + +A suitable name search must be successfully completed before a podling can graduate. +This isn't the only way one might be done, just a smooth path. + +Names are an essential part of building a brand and community. +Switching names wastes the efforts put into establishing the original name. +Therefore complete this task as soon as possible. + +== Conducting A Suitable Name Search + +The aim - to find a name that is acceptable to the community and is not unsuitable. + +A suitable name search has public and private elements. +The link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[tracker] provides the public record. +Incubator best practice evolves over time, documentation lags. +The public records of past searches are a primary source of guidance. +Review now the records of previous searches, beginning with the most recent then working back. + +The public record consists of _actions_ (how you searched) and _facts_ (what your search found). In particular, +in *all* public forums (mailing lists, issue trackers and so on): + + +-*Do not* speculate. +-*Do not* use loaded technical legal language. +-*Do not* offer + -opinions, + -advice, + -interpretation, or + -analysis. + +Use the public lists in the Incubator to ask questions about _how_ the search should be conducted. +Once the information is collected and collated, then ask the trademark team to help interpret and analyse these results +on the private lists, copying in the PPMC. Finally discuss the results of your investigation on the private PPMC list. +Whether a name is suitable or unsuitable (or somewhere in between) should be recorded when the issue is closed. + +=== Eliminate Unsuitable Names +To be suitable, a name needs to be + +- judged _appropriate_ by the wider community; and +- _unique enough_ to avoid confusion + +Facts and activities performed are link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[recorded] for the public. +Interpretation and analysis of these facts happens on private mailing lists, the PPMC private in the first instance. +Whether the name proved suitable or unsuitable should be entered into the public record +but take care to use our language (_ethically unsuitable_ or +_not unique enough_) and to avoid loaded legal terms. + + +==== The Main Sequence + +Every podling is unique, but using a link:http://outreach.atnf.csiro.au/education/senior/astrophysics/stellarevolution_mainsequence.html[cosmic] +metaphor, most fit into a main sequence. For podlings on the main sequence, +most of the bugs should have been squashed and rough edges documented away, so expect a smooth journey. +Away from the main sequence, process may need to be grown, documentation is likely be sparse +and progress less smooth. + +The main sequence is described here. This well known path is +appropriate for almost all podlings. +If there are good reasons to think that your podling is a special case, discuss this with the +link:http://mail-archives.apache.org/mod_mbox/incubator-general/[Incubator community] +and reach consensus on the way forward. + +==== Appropriateness + +Some names are not appropriate for open source projects. +Acceptability under +link:http://www.law.cornell.edu/uscode/15/1052.shtml[US Trademark Law] is a good base line. +This excludes marks that + +[quote] +---- +Consists of or comprises immoral, deceptive, or scandalous matter; +or matter which may disparage or falsely suggest a connection with persons, +living or dead, institutions, beliefs, or national symbols, or bring them into contempt, or disrepute; +---- +-- link:http://www.law.cornell.edu/uscode/15/1052.shtml[US Code 15:1052] + +Proposals with inappropriate names are unlikely to pass the initial hustings but spend a few moments considering +whether anything has been missed. Check for alternative meanings, perhaps in foreign languages. + +==== Unique Enough Names + +The name needs be unique enough to avoid confusion with software that already exists. +For the community to be able to protect its reputation for quality and openness, +its name needs to unique enough to have potential as a trademark. + +But this isn't only about being able to register trademark protection. +Ethics also plays a role. Even where a name may offer enough protection, existing adoption +of the name by an active community may mean that the choice needs to be eliminated on ethical grounds. +There is some judgment involved in this decision. So, involve the wider Incubator community if a name is already +used. + +==== How To Collect Evidence Of Uniqueness + +To decide whether a potential name is _unique enough_ to be suitable + +- Collect evidence about current name usage. +- link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] the facts. +- Analyse and interpret these facts; in private with help from the brand team. +- Reach consensus about whether the name is unique enough. +- link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] whether the name is suitable. +- If unsuitable then the community should pick a more unique name and repeat this process. + +==== Evidence Of Open Source Adoption + +Existing adoption amongst another active open source community may give ethical +reasons for eliminating a name. This is an example of a condition with a fractal +boundary. Not every name which has been used before need be eliminated as unsuitable +but this is an issue which needs to be discussed more widely and +a consensus reached with the broad +link:http://mail-archives.apache.org/mod_mbox/incubator-general/[Incubator community]. + +Look for evidence of existing adoption amongst open source communities by searching well known +foundries (for example link:http://www.github.com[GitHub] and +link:http://www.sourceforge.net[Sourceforge]) +and the web (use several search engines for example link:http://www.bing.com[Bing], +link:http://www.google.com[Google] and link:http://www.yahoo.com[Yahoo]). +Review recent link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[records] +for contemporary details about where to search. +link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] each search and describe the results. + +If the name been used by the same community before it arrived at Apache, that's fine but should be noted in the +link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[record]. + +=== Evidence Of Registration + +A number of online resources exist which may help to discover evidence of +competing registered trademarks. +Not every trademark is registered. Not every registered trademark is listed in these resources. +Even if evidence is found of existing registrations, +this does not necessary eliminate the proposed name. Just +link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[record] the facts. +Leave analysis and interpretation to private lists. +When a search returns a large number of hits, focus on live registrations related to software. + +The foremost online resource is TESS run by USPTO. Before using +TESS, please browse the documentation links from +link:http://www.uspto.gov/trademarks/index.jsp[USPTO trademark home]. + +Other resources which allow cheap searches of their databases exist but are often +ephemeral. Review the link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[records] +for the state of this art. + +==== Evidence Of Use On The World Wide Web + +Registration of trademark is not required. Rights may also be obtained by use of a mark in commerce. + +Use a variety of web search engines (for example, link:http://www.bing.com[bing], link:http://www.google.com[google] +and link:http://search.yahoo.com[yahoo]) to survey usage on the world wide web. +-The results returned by a search for the name itself may provide evidence of well known usages of the term. +-The results returned by searching for the name and _software_ may provide evidence of existing use in trade. You may also want to search for the name and key functionality the software provides +and name and _open source_ --------------------------------------------------------------------- To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org For additional commands, e-mail: cvs-help@incubator.apache.org