Mentors' Guide

X-Mailer: ASF-Git Admin Mailer Subject: [39/51] [partial] incubator git commit: Automatic Site Publish by git-site-role archived-at: Thu, 13 Jul 2017 01:36:02 -0000 http://git-wip-us.apache.org/repos/asf/incubator/blob/73f8b0f7/content/guides/mentor.html ---------------------------------------------------------------------- diff --git a/content/guides/mentor.html b/content/guides/mentor.html new file mode 100644 index 0000000..1966268 --- /dev/null +++ b/content/guides/mentor.html @@ -0,0 +1,525 @@ + + + + + Mentors' Guide + + + + + + + + + + + + + + + + + + + + + +

+ + + + +

+ + + +

+ +Estimated Reading Time: + +

Table of Contents

Overview
Add to Incubation Summary file
Initialize Podling Status Page
Resources +
- Request Required Resources
+
[DRAFT] Podling Bootstrap
Mentors MUST be on the IPMC
CLA and CCLA Submission

The Mentors' guide is a go-to place for information about getting a podling up and running from an infrastructure point of view.

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 Responsibilitiesdocument.

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.

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. Below is an example of the final XML snippet

    <podling name="PodlingName" status="current" resource="podlingname" sponsor="Sponsor" startdate="YYYY-MM-DD">
+        <description>A description of the podling, for the status page and reports</description>
+        <reporting group="1|2|3" monthly="true">First,Second,Third</reporting>
+        <champion availid="userid">Champion Name</champion>
+        <mentors>
+            <mentor username="userid">Mentor One</mentor>
+            <mentor username="userid">Mentor Two</mentor>
+            <mentor username="userid">Mentor Three</mentor>
+        </mentors>
+    </podling>

An example reporting block:

<reporting group="3" 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 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.

Resources

Resources should be requested in a particular order, and based on paperwork processed. Do not request source repositories before SGAs are filed, for instance.

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 +link:https://infra.apache.org/officers/mlreq/incubator" target="_new[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 link:https://lists.apache.org" target="_new[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

Request an issue tracker on the infra service desk

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

[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:

+
Ensure Mentors are on the IPMC[Mentors]
+
+
Add podling to reporting schedule [IPMC member]
+
+
Initialize project status page [IPMC member]
+
+
Start orientation [Prospective committers]
+
+
Start CLA and CCLA submission [Prospective committers]
+
+
Start IP Clearance [IPMC member]
+
+
Request Required Resources — Mailing Lists [Infrastructure Team] +--- Consider and plan transition to official mailing lists — Subversion [IPMC] — Issue Tracking [Infrastructure Team] +--- Consider and plan issue tracking transition
+
+
Create website [Prospective committers] — Consider and plan web site transition
+

Mentors MUST be on the IPMC

Mentors MUST be on the IPMC. This should be checked prior to beginning incubation. +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.

+ +

+ + + + + + + + + + + http://git-wip-us.apache.org/repos/asf/incubator/blob/73f8b0f7/content/guides/names.html ---------------------------------------------------------------------- diff --git a/content/guides/names.html b/content/guides/names.html new file mode 100644 index 0000000..eaa74c4 --- /dev/null +++ b/content/guides/names.html @@ -0,0 +1,554 @@ + + + + + Podling Name Search Guide + + + + + + + + + + + + + + + + + + + + + +

+ + + + +

+ + + +

+ +Estimated Reading Time: + +

Table of Contents

Introduction +
+
Conducting A Suitable Name Search +
- Eliminate Unsuitable Names
- Evidence Of Registration
+

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 incubator general.

Meet The Apache Branding Team

Names fall within the responsibilities of the +V.P., Brand Management (and +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 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 Apache Software Foundation is +a US corporation. +Developing some understanding of the basic principles of US trademark law is therefore important.

Please read:

+
Description of key trademark principles for Apache projects;
+
+
USPTO trademark
+
+
home page
+
+
basics, and follow the links for materials;
+
+
US Trademark Law WikiBook; and
+
+
Passport Without A Visa: Open Source Software Licensing and Trademarks by Tiki Dare and Harvey Anderson in the International Free and Open Source Software Law Review.
+

Trademarks And The Apache License

Like many +open source licenses, the +Apache License, Version 2.0 +focuses on granting copyright and patent rights to the public. +The trademark section permits only very limited trademark rights.

+
+
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."
+
+

— 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 +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 +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 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 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 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 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 +Incubator community +and reach consensus on the way forward.

Appropriateness

Some names are not appropriate for open source projects. +Acceptability under +US Trademark Law is a good base line. +This excludes marks that

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;

— 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.
+
+
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.
+
+
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 +Incubator community.

Look for evidence of existing adoption amongst open source communities by searching well known +foundries (for example GitHub and +Sourceforge) +and the web (use several search engines for example Bing, +Google and Yahoo). +Review recent records +for contemporary details about where to search. +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 +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 +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 +USPTO trademark home.

Other resources which allow cheap searches of their databases exist but are often +ephemeral. Review the 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, bing, google +and 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

+ +

+ + + + + + + + + + + http://git-wip-us.apache.org/repos/asf/incubator/blob/73f8b0f7/content/guides/participation.html ---------------------------------------------------------------------- diff --git a/content/guides/participation.html b/content/guides/participation.html new file mode 100644 index 0000000..f64713b --- /dev/null +++ b/content/guides/participation.html @@ -0,0 +1,332 @@ + + + + + Guide to Participation + + + + + + + + + + + + + + + + + + + + + +

+ + + + +

+ + + +

+ +Estimated Reading Time: + +

Table of Contents

General Netiquette
Ways To Participate +
- On The General Mailing List
- As A User
- As A Developer
- As A Committer
- As A Mentor
- On The Incubator PMC
+

This document is descriptive, not normative. It aims to help those who are new +to the Incubator learn its ways and netiquette.

General Netiquette

The usual advice applies. If you are not familiar with the way mailing lists +work at Apache, read this.

Please ensure that your mail client is correctly configured. In particular, post only plain +text emails to these lists. Apache spam filters may reject HTML emails.

The incubator is a public meeting place with a diverse and ever-changing community. +Creating social bonds and establishing a reputation is important. Please be polite, +courteous and diplomatic.

When in doubt - ask on general.AT.incubator.apache.org.

Ways To Participate

On The General Mailing List

The general.AT.incubator.apache.org is an public list with open subscription. +All are encouraged to subscribe, read and post their opinions in the usual way.

Anyone can by their words influence the decision-making process and may vote on +VOTE threads. +However (as is usual) only the votes of those on the +Incubator PMC are binding.

As A User

A user +is anyone who uses our software. Most Apache projects have active user +communities who are willing to provide help. This is not always the case with incubator podlings.

To gain the maximum benefit from any immature project (as many podlings are), +adopt an active attitude. +Read On Contributing +and +Understanding Open Source. +Become a developer (in the Apache meaning of the term).

As A Developer

At Apache, a developer +(aka contributor) is anyone who actively helps to develop our software. This includes more than just coders +and documenters. For example, anyone who joins in discussions on the mailing lists or answers questions +from users is also a developer.

Apache is a DO-ocracy. The first step along the road leading to +committership is to become a developer. For more information start with +How Apache Works +and the developer documentation.

As A Committer

A committer +is anyone with write access to the source repository. Election to committership in the Incubator +works a little differently from the process that is usual elsewhere at Apache.

Once a podling has been bootstrapped, developers are nominated +and election to committer happens in the usual way.

When a proposal is just a candidate, +there are two possible approaches (for those interested in committership).

The proposal typically +contains a list of initial committers. +When a podling is bootstrapped, this list is used by the mentors to set up initial accounts. +So, one way to become a committer for a podling is to be listed on the proposal as an initial +committer.

The right way to express interest is by a post to the list with a brief introduction. +Piling onto a proposal (by adding your own name as an initial committer) is impolite. +Read +3cC73C6D24-3216-4EB4-8846-1218B38CC594@gbiv.com%3e">this thread.

A podling needs to learn how to recruit new committers from its developers. So, +another way is to show up on the list and start helping with the development. +This path will help the podling more than adding your name to the list of initial committers.

As A Mentor

Anyone with knowledge of open source or Apache can participate as a informal mentor +for a podling. Development is open and anyone with an interest is encouraged to +subscribe.

Eligibility to act as a formal +Mentor is +limited. The best way for an eligible +individual to become a Mentor is to post a note introducing him- or herself +and volunteering their services to general.AT.incubator.apache.org +during the development of the proposal.

On The Incubator PMC

Apache Members are encouraged to join the +Incubator PMC. Post a note to the Incubator PMC private list.

Those who aren’t members may be elected in the usual Apache way. These elections are held on private lists.

+ +

+ + + + + + + + + + + http://git-wip-us.apache.org/repos/asf/incubator/blob/73f8b0f7/content/guides/pmc.html ---------------------------------------------------------------------- diff --git a/content/guides/pmc.html b/content/guides/pmc.html new file mode 100644 index 0000000..ad00b47 --- /dev/null +++ b/content/guides/pmc.html @@ -0,0 +1,214 @@ + + + + + The Incubator PMC + + + + + + + + + + + + + + + + + + + + + +

+ + + + +

+ + + +

+ +Estimated Reading Time: + +

Table of Contents

Joining the IPMC
Members
Roles and Responsibilities of the IPMC

Joining the IPMC

Joining the IPMC is just like any other PMC, once enough merit and community involvement is performed, PMC members will take notice and may vote on you to join.

Foundation members may willingly join the IPMC at any time, to express desire send an email to private.AT.incubator.apache.org

Members

A full list of IPMC members can be found at home.apache.org/phonebook.html?pmc=incubator

Roles and Responsibilities of the IPMC

The full list of expectations of an IPMC member can be found on the +Roles & Responsibilities Page

+ +

+ + + + + + + + + + + --------------------------------------------------------------------- To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org For additional commands, e-mail: cvs-help@incubator.apache.org

Guide :: Mentors' Guide

Overview

Add to Incubation Summary file

Initialize Podling Status Page

Resources

Request Required Resources

Request Mailing Lists

Mail Archives

Mailing List Administration

Mailing List Transition

Issue Tracking

[DRAFT] Podling Bootstrap

Mentors MUST be on the IPMC

CLA and CCLA Submission

Guide :: Podling Name Search Guide

Introduction

Meet The Apache Branding Team

Trademarks

Trademarks And The Apache License

What Makes A Name Good

Podling Suitable Name Search

Conducting A Suitable Name Search

Eliminate Unsuitable Names

The Main Sequence

Appropriateness

Unique Enough Names

How To Collect Evidence Of Uniqueness

Evidence Of Open Source Adoption

Evidence Of Registration

Evidence Of Use On The World Wide Web

Guide :: Guide to Participation

General Netiquette

Ways To Participate

On The General Mailing List

As A User

As A Developer

As A Committer

As A Mentor

On The Incubator PMC

Guide :: The Incubator PMC

Joining the IPMC

Members

Roles and Responsibilities of the IPMC