Difference between revisions of "Development Resources/HOWTO/Pre-Proposal Phase"
(→Clear, Concise, and Understandable Proposal)
(Only EMO can set working group categorization.)
|Line 36:||Line 36:|
* Provide a project name.
* Provide a project name.
* Click "I know what I'm getting into" checkbox.
* Click "I know what I'm getting into" checkbox.
Revision as of 15:23, 7 July 2014
See "6.2.1 Pre-Proposal Phase" in the Eclipse Development Process
An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.
- The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.
- 1 Project or Contribution?
- 2 Project Name
- 3 Clear, Concise and Understandable Proposal
- 4 Mentors
- 5 Posting and Declaration
- 6 Press and Publicity
- 7 Legal Paperwork to Start Now
- 8 Next Steps
Project or Contribution?
One of the major purposes of the Eclipse Development Process is to ensure that the projects are open and transparent to the membership and ecosystem. Another major purpose is for the Councils to minimize duplication across the projects, i.e., we strive to have one official Eclipse framework for each technical area. Thus, as the first step in a new proposal, we ask four questions:
- Is there already a Project at Eclipse working the same technical area (i.e., a Project whose scope includes this area)?
- If so, would this proposal be more suited as a contribution to that project or a new sub-project of that existing project?
- Note that an overlap between projects is not prohibited but is strongly discouraged. The Eclipse membership has indicated that they are ok with multiple incubating projects in a given technical area, but would prefer a single project once the frameworks mature.
- In all "competing project" situations to date, the projects eventually realized that it would be in their best interest to work together and thus merged their projects before graduating.
- Is this new effort going to be managed as part of an existing project or is it going to be a separate entity?
- Here we examine the interaction of the project leads and the synchronization (or lack thereof) of release schedules. For example, if the new effort is always going to release at the same time as another project and the leads of the new effort and the other project are regularly coordinating development plans, then perhaps this new effort is a component of the other project. Otherwise, if the new effort is more independent (in management and in release schedule), then perhaps it should be a separate project.
- Is this new effort within the scope of the (optionally) enclosing parent Project and charter of the enclosing Top-Level Project? For example, a new "syntax highlighting editor for Pascal" would not be in scope of the "Web Standard Tools" project.
The new effort must be in scope with respect to its enclosing Project(s).
Naming and branding are challenging issues. In order to provide a consistent brand for Eclipse, projects must follow the project naming guidelines which effectively say:
- The best names are descriptive but at the same time memorable.
- The project name does not include "Eclipse" or "Project".
- The project name is not the name of an existing product and will not be used in the name of a product.
Clear, Concise and Understandable Proposal
Create a proposal here.
We provide a template that you fill in with the proposal details.
- Use plain non-technical English.
- Describe all acronyms.
- Provide urls where appropriate to direct reader for further information.
- Provide a project name.
- Click "I know what I'm getting into" checkbox.
- Describe where the project came from. What is the historical journey of the project; who/what company wrote the project. Did it go through any significant alterations/rewrites/language changes?
Provide an introductory paragraph describing what the project aims to be followed by several bullet points ie.
Trace Compass is a tool for viewing and analyzing any type of logs or traces. Its goal is to provide views, graphs, metrics, etc. to help extract useful information from traces, in a way that is more user-friendly and informative than huge text dumps. It aims to provide: + Provide both a stand-alone RCP application and a standard Eclipse plugin. + A core framework written in Java that exposes a generic interface for integration of trace types. + Support for custom text or XML parsers that can be added right from the graphical interface by the user. + Support for the following trace formats natively (no third-party libraries needed): + The Common Trace Format (CTF) (with specialized views for the LTTng kernel and user space tracers) + GDB traces + The Best Trace Format (BTF) + Provide support for the libpcap format. This is used in most network traces. + A repository of application-specific or problem-specific modules of all known trace type integration plugins. + Support for live trace readings. + Support for the new features in LTTng 2.5+. + Add more types of data-driven views and improve the existing ones. Out of scope for the project //
The scope should allow for some flexibility, but still provide well-defined boundaries for the project.
- What is in-scope?
- What is out-of-scope?
- Clear, concise and easily understood by everyone. It is important that the description of the new project be understandable by the diverse Eclipse community and not just by specialists in the subject matter. It is also important that the description concentrate on the technical aspects of the project and avoid marketing buzzwords. Terms that are not in common use amongst the Eclipse membership must be defined, and references to standards should be linked to the corresponding URL.
- A thought experiment for clarity and conciseness is "if I randomly choose five Committers from the entire Eclipse Committer pool, will those five people understand what this project is about?" The five may not agree with the proposal or even believe that it is feasible, but they need to understand what it is proposing.
- The fit with Eclipse. How does this project fit with the other Eclipse projects? Does it build on top of other projects? What are the dependencies? Does it overlap with existing projects? Why are the needs this project meets are not met by existing Eclipse projects?
- Why Eclipse? The proposal should provide some discussion of why The Eclipse Foundation is the right place for the project to live. What do you expect to gain by having your project at Eclipse? What value does the project provide to the Eclipse community and eco-system?
- Resources committed. Eclipse is a place for active projects, not a place for dumping unwanted code. Eclipse projects involve substantial on-going development activity. Thus proposals should be convincing about the resources that are being brought to the project in addition to any initial code contribution. The proposal should include a list of interested and committed persons and companies and their affiliations, but should not include corporate or group logos.
- Vendor neutral. Eclipse is place for vendor neutral projects which includes being operating system agnostic. If, as is usually the case, the proposal is coming from a single company, the proposal should explain how the resulting project will be vendor neutral. Similarly, the proposal should explain away any operating system dependencies.
Previous Proposals to Emulate
Proposal File Format and Submission
The proposal itself is a static HTML page (with a small fragment of PHP) using the standard Eclipse Proposal CSS style sheet (please use the template we provide). This template is heavily annotated with information and help; we suggest that you start there. Further, this document has been evolved to the point where it includes sufficient information to also serve as a Creation Review document.
We have found that there are a number of problems with HTML generated by Microsoft Word and thus ask that proposers use some other tool to create the page using only simple, static, standard HTML (let our stylesheet work its magic). Sorry, but the EMO does not have the time or resources to convert other file formats to the correct static HTML.
Proposals must be zipped (to avoid problems with the Foundation's email anti-virus scanner) and emailed to firstname.lastname@example.org.
New projects (i.e., incubating projects) at Eclipse require the supervision of at least two Mentors. The proposal can be posted prior to selecting mentors, but it cannot have a Creation Review without mentors. Thus it behooves the proposers to begin finding mentors as early as possible.
Posting and Declaration
After the EMO receives and agrees the proposal is ready to post, the following steps are taken:
- The EMO modifies the proposal text to include the correct internal Foundation database record identifier and the correct discussion newsgroup.
- The proposal is placed at a hidden url on the eclipse.org website.
- The EMO drafts a declaration. The declaration is a short email message sent by the EMO to the Eclipse membership-at-large stating that X is proposing project Y at Eclipse. The declaration has the following form:
We are notifying the Eclipse Membership-at-Large of the intent of Person P (Company Q) to propose the XYZ Project as a EFG incubator. A brief description of the project is below. A draft project proposal has been posted on http://www.eclipse.org/proposals/xyz/ ------------------------------------------------------------------------ *Project Declaration for the "XYZ Project" The goal of this project is to add comprehensive support blah blah blah...
- The EMO requires positive approval from at least three people before publicly posting the proposal and sending the declaration. All three people (or their appointed delegates) must reply that they are ok (+1) with the hidden-url proposal and the declaration before the proposal will be made public.
- The proposer, speaking for all the people and companies involved
- The Eclipse Foundation's Director of Committer Community
- The Eclipse Foundation's Executive Director
- The EMO updates the internal Foundation database, thus publishing the proposal on the website. At the same time, the EMO creates the corresponding discussion newsgroup.
- The EMO sends you an email reminding you to read and implement the Guidelines for the Proposal Phase
Press and Publicity
History has shown that companies who are starting or joining their first open-source project, or perhaps merely their first Eclipse open-source project, want to carefully stage the press announcements. Because the Eclipse membership-at-large is large and includes press, the EMO works carefully with the proposers to ensure that news is not prematurely leaked.
A press release at this point is optional. Some companies and individuals like to have a press release when the project is proposed, while others prefer to wait until the project is approved/created, and then others do not issue one at all - it is completely up to the proposal team. Any release must include Q&A's, messages and preparation by the stakeholder spokespeople. The discipline of creating a press release ensures that all stakeholders have agreed on messages, positioning and have identified spokepersons.
If you do decide to issue a press release, the Eclipse Foundation Marketing Director must help you coordinate the announcement. (Email the EMO for further information.)
Legal Paperwork to Start Now
It is important for the proposers to begin moving the various Committer Agreements through their company's legal department as the paperwork always seems to take longer than one would like. The project cannot be provisioned (source code repository, bug repository, website, etc.) without completed legal paperwork.
Similarly, the proposers will want to start gathering the required documentation for the initial code contribution questionnaire. The important information includes:
- Documentation of code ownership and the right of the proposer to contribute the code under the EPL
- Licenses, source code, and provenance of all third-party (non-EPL) code included or referenced in or by the EPL'ed initial code.
- And by all, we mean ALL the code: many third-party libraries include other third party libraries and those include others and so on and so on.
A proposal is generally posted for a minimum of two weeks. During this period, you should actively monitor the communication channel for the proposal and make sure that you address the needs of your burgeoning community. Provide updates to your proposal to the EMO.
Proposals that languish for more than three months will be withdrawn by the EMO.
When you are ready to create the project, inform the EMO. The proposal document itself can serve as the "Creation document" for the Creation Review. Prior to scheduling the creation review, however, the EMO will initiate a trademark search on the desired name for your project. This process may require trademark reassignment to the Eclipse Foundation. The trademark search must be completed before the review can be scheduled.
This page is moderated by the EMO