Project Proposal Guidelines

Farhangi edited this page Jan 25, 2013 · 22 revisions

An individual or group of individuals declares their interest in, and rationale for, establishing a project. The Mentoring Board as well as the ecosystem project will assist such groups in the preparation of a project Proposal. Therefore contact the project office and/or the ecosystem project in the pre-proposal phase and allow them to work together with the groups proposing a project to create the proposal.

The Pre-proposal phase ends when the Proposal is published by the ecosystem project and announced to the openETCS project partners.

Project or Contribution?

One of the major purposes of the openETCS Development Process is to ensure that the projects are open and transparent to the openETCS participants and ecosystem. Another major purpose is to minimize duplication across the projects, i.e., we strive to have one official openECTS project for each area. Thus, as the first step in a new proposal, we ask four questions:

  • Is there already a Project at openETCS working the same 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 openETCS project is ok with multiple incubating projects in a given technical area, but would prefer a single project once the project is 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 project can be part of the top level projects WP1, Wp2, WP3a, WP3b and so on.

The new effort must be in scope with respect to its enclosing Project(s).

Project Name

Naming is a challenging issue. In order to provide a consistent name, 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 "openETCS" 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

The next step in establishing a new project at openETCSis to contact the project office (project office; email projectoffice@openetcs.org) and work towards a clear, concise, and understandable Proposal.

The Proposal includes:

  • Clear and concise description. It is important that the description of the new project be understandable by the diverse openETCS 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 openETCS 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 people from the entire openETCS project, 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.
  • Well-defined Scope. What is in-scope? What is out-of-scope? The scope should allow for some flexibility, but still provide well-defined boundaries for the project.
  • The fit with openETCS. How does this project fit with the other openETCS 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 openETCS projects?
  • Why openETCS? The proposal should provide some discussion of why openETCS is the right place for the project to live. What do you expect to gain by having your project at openETCS? What value does the project provide to the openETCS community and eco-system?
  • Resources committed. openETCS is a place for active projects, not a place for dumping unwanted code or document. openETCS 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. openETCSis 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.
  • Mailinglist for discussion. Please see the infrastruture page how to join a mailing list. All questions and comments about a proposal are posted to proposal@openetcs.org and are therefore visible to the community. All initial committers as well as the proposed project leads must be activly participate in this mailing list.

Previous Proposals to Emulate

Past proposals are available at the proposals page.

Proposal File Format and Submission

The proposal itself is a github wiki page (please use this template we provide). This template is annotated with information and help; we suggest that you start there. Proposals must be emailed to projectoffice@openetcs.org.

Mentors

New projects (i.e., incubating projects) at openETCS 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. There are two types of Mentors, domain mentors and process mentors. A domain mentor should be familiar with the domain aspects of the project. The process mentor should be familiar with the openETCS development process.

Posting and Declaration

After the project office receives and agrees the proposal is ready to post, the following steps are taken:

  • The proposal is placed at the wiki of ecosystem top-level project.
  • The project office drafts a declaration. The declaration is a short email message sent by the project office to the openETCS participants stating that X is proposing project Y at openETCS. The declaration has the following form:

We are notifying the openECTS community of the intent of Person P (Company Q) to propose the XYZ Project as a incubator. Questions and discussions of the community are posted to proposal@openetcs.org

A brief description of the project is below. A draft project proposal has been posted here (link)

  • The project office sends you an email reminding you to read and implement the Guidelines for the Proposal Phase

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 a possible initial code contribution questionnaire. The important information includes:

  • Documentation of code ownership and the right of the proposer to contribute the code under the EUPL
  • Licenses, source code, and provenance of all third-party (non-EUPL) code included or referenced in or by the EUPL'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.

Next Steps

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. A very important change to the initial proposal might be to include initial committers. Any interested participant can ask the proposer to add him/her as an initial committer to the proposed project. NOTE: Committers can only be elected, once the project is created. Provide updates to your proposal to the ecosystem project.

Proposals that languish for more than three months will be withdrawn by the ecosystem project.

When you are ready to create the project, inform the project office. The proposal document itself can serve as the "Creation document" for the Creation Review.