Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Architecture Council/Things Committers Should Know/Staging"

(December 2008)
(Links to non-eclipse.org content)
 
(21 intermediate revisions by 3 users not shown)
Line 31: Line 31:
 
*Use Import-Package instead of Require-Bundle
 
*Use Import-Package instead of Require-Bundle
  
=December 2008=
 
==Intellectual Property Due Diligence==
 
Hello Eclipse Committer. This is a first note in a new series of "Things Committers Should Know". Each month, the Architecture Council [1] sends out a short note describing some important aspect of life as an Eclipse committer. We hope that these notes are valuable and informative. For more information, please see the "Things Committers Should Know" page[2].
 
  
This month, we're going to touch briefly on Intellectual Property (IP) Due Diligence.
 
  
The Eclipse Intellectual Property Due Diligence Process poster [3], accessible from the Legal Resources page on eclipse.org, describes various scenarios for including intellectual property (IP) into an Eclipse project. As an Eclipse Committer, you should be familiar with this poster. This poster is just one part of the IP Due Diligence story. As an Eclipse Committer, you also need toy be aware of the "Guidelines for the Review of Third Party Dependencies" [4] which describes the IP Due Diligence process as it pertains to dependencies in your code to code provided by a third-party.
+
=Future=
  
In the coming months, we'll talk more specifically about these important resources. In the meantime, if you have any questions about the IP Due Diligence process, please ask your project leader, your PMC, or one of your project's Architecture Council mentors.
+
==Reviews==
 +
You need to have a review for any release of your project. This includes "incubation" releases (0.x). Downloads for a project in incubation need to be clearly labeled.
  
[1] http://wiki.eclipse.org/index.php?title=Architecture_Council
+
==Links to non-eclipse.org content==
[2] http://wiki.eclipse.org/index.php?title=Architecture_Council/Things_Committers_Should_Know
+
Occasionally, you may want or need to provide links to external content [1] from your project website. Several projects do this today: it's an excellent way to provide more information for your project, and help to make your project become part of the community. Some projects link to websites that showcase how the project's code is being used by the community, some to FAQs and other sources of information.
[3] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
+
[4] http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
+
=Future=
+
==Do I need a Contribution Questionnaire?==
+
  
 +
The content on the Eclipse website and wiki is subject to the Eclipse Terms of Use [2]. Information, downloads, and other kinds of information found on other websites are likely subject to different terms of use. In consideration of this, it is critical that your project's consumers are made explicitly aware of where the Eclipse project's website ends and the third-party site begins.
  
Several of these "Things Committers Should Know" messages will deal focus on the Eclipse IP process. We'll start the series with the simplest possible scenario.
+
You can provide links from your Eclipse project's web site to external resources (e.g. binaries, code, etc.), provided that:
  
You're an Eclipse committer. You've created a contribution that provides some significant new functionality (i.e. it's more than just a couple of lines of code written as part of the ongoing development of an existing component). The new contribution was developed from scratch and you have consented to releasing it under the Eclipse Public License [2]. The contribution has been written under the supervision of the Project Management Committee (PMC), and contains no cryptography. If this describes what you've done, then a contribution questionnaire is not required; you can commit into CVS/SVN. You must record the contribution in the project's IP Log.
+
#There is some adequate disclaimers that make it clear that although this is a "related link" that this is not Eclipse content.
 +
#The link to the existing code is not just be a direct link to content. It has to be a link to a download page on the external site.
 +
#The link to their download page needs to be such that it brings up an entirely new browser so that it is made even more apparent to the user that they are leaving the eclipse.org website.
  
Here are some clarifications:
+
[1] http://wiki.eclipse.org/Development_Resources#Committers_and_The_Eclipse.Org_Website
  
For IP due diligence purposes, the definition of contribution means any content, including code, data/metadata files, images, fonts, etc.
+
[2] http://www.eclipse.org//legal/termsofuse.php
  
In this scenario, "developed from scratch" means that all content is new; no existing content from other sources has been included (i.e. no copy and paste). Further, "developed from scratch" means that the content does not rely on the IP of others. That is, the content relies only on existing
+
==Do I need a Contribution Questionnaire?==
  
What it means for a contribution to have been developed "under the supervision of the PMC" can vary from PMC to PMC. "Supervision" could mean that the functionality provided by the contribution is described in your project plan or in an existing Bugzilla record. Alternatively, it could mean that the functionality has been openly discussed in your project's mailing list, or that the PMC has been directly informed of the ongoing work. Ultimately, you should ask your PMC how they define "supervision".
+
The Intellectual Property (IP) Due Diligence team has been getting a lot of unnecessary contribution questionnaires (CQ). The Eclipse Legal Process Poster [1] is the definitive guide to the process. The first two tracks through this process are the easiest.
  
 +
Track One: If a contribution is 100% written by an existing project committer, under supervision of the Project Management Committee (PMC), contains no cryptography, was 100% developed from scratch, and is 100% EPL [2], then you don't need a CQ.
 +
 +
Track Two: Similarly, if a contribution is 100% written by employees of a company that has signed a Member Committer Agreement, under supervision of the PMC, contains no cryptography, was 100% developed from scratch, and is 100% EPL, then you also don't need a CQ;
 +
 +
If either of these scenarios are true, then your contribution does not require a CQ and can be committed directly into the project's source code repository. An entry in your project's IP Log is required.
 +
 +
The definition of "under supervision of the PMC" bears some scrutiny. At a minimum, for a contribution to meet this criteria, at least one of the existing project committers must have been involved with the development of the contribution from its inception and the contribution must provide functionality that is within the project's scope. Further, the community at large must have been given reasonable notification that the contribution was under development. Notification can take the form of discussion in a project mailing list, newsgroup, Bugzilla record, or project plan.
 +
 +
Your PMC may have additional requirements in their definition of "supervision"; if you have any questions, ask your PMC. If you're not sure if your contribution qualifies for either of these first two tracks, ask your PMC for help. If you're still not sure, file the CQ anyway.
  
 
[1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
 
[1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
 +
 
[2] http://www.eclipse.org/org/documents/epl-v10.php
 
[2] http://www.eclipse.org/org/documents/epl-v10.php
 +
 +
==Component == Project==
 +
Recent changes to the development process [1] have formalized the notion of arbitrarily nested projects, otherwise known as sub-projects. One of the implications of this change is that the former notion of a component effectively no longer exists. What we formerly referred to as a "component" is now just a sub-project. Sub-projects have their own set of committers (i.e. the source tree in the project's code repository has its own UNIX group describing who has commit privileges), their own release schedule, their own website, and more. Creation of a new sub-project requires a project proposal, followed by a creation review, and project provisioning.
 +
 +
The development process describes a project that itself has no sub-projects as an "Operating Project" and states that an Operating Project owns and maintains a collection of source code and/or web pages. A project that does have sub-projects, is described as a "Container Project"; Container Projects may have their own web pages, but do not have their own code repository. Effectively, this means that you can only have code in the leaf nodes of the project tree.
 +
 +
[1] http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization
 +
 +
[[Category: Architecture Council Committer Resources]]

Latest revision as of 20:54, 16 March 2009

On this page, members of the Architecture Council assemble the notes that are sent out to committers as part of the Architecture Council/Things Committers Should Know effort, designed to arm Eclipse Committers with as much information about the Eclipse Development Process as possible.

Ideas

Here are some ideas for future notices.

  • The My Foundation Portal
  • Contributing to Eclipse Corner
  • Contributing Resources
  • What is a Contribution Questionnaire?
  • What does the PMC do anyway?
  • What does the Eclipse Foundation Do?
  • Finding answers to legal questions
  • What belongs in the repository?
  • How do I contribute bundles to Orbit?
  • Aggregate your blog on planet Eclipse
  • How do I propose a new project?
  • How do I get free Eclipse Swag?
  • Getting started with CBI
  • Where I can find download statistics for my project?
  • How do I 'listen in' on Bugzilla conversations
  • How do I ensure API Compatibility in a new version
  • How do I treat dependencies to external libraries
  • How do I build a Community for my project
  • How do I encourage users to submit patches
  • How do I get useful bug reports from users
  • How do I get started with unit tests
  • How do I report a problem with Eclipse web infrastructure
  • How do I suggest an improvement to the Eclipse Foundation
  • Can I commit code that I wrote before becoming committer?
  • How do I get my Strings externalized and translated by the Community
  • Use Import-Package instead of Require-Bundle


Future

Reviews

You need to have a review for any release of your project. This includes "incubation" releases (0.x). Downloads for a project in incubation need to be clearly labeled.

Links to non-eclipse.org content

Occasionally, you may want or need to provide links to external content [1] from your project website. Several projects do this today: it's an excellent way to provide more information for your project, and help to make your project become part of the community. Some projects link to websites that showcase how the project's code is being used by the community, some to FAQs and other sources of information.

The content on the Eclipse website and wiki is subject to the Eclipse Terms of Use [2]. Information, downloads, and other kinds of information found on other websites are likely subject to different terms of use. In consideration of this, it is critical that your project's consumers are made explicitly aware of where the Eclipse project's website ends and the third-party site begins.

You can provide links from your Eclipse project's web site to external resources (e.g. binaries, code, etc.), provided that:

  1. There is some adequate disclaimers that make it clear that although this is a "related link" that this is not Eclipse content.
  2. The link to the existing code is not just be a direct link to content. It has to be a link to a download page on the external site.
  3. The link to their download page needs to be such that it brings up an entirely new browser so that it is made even more apparent to the user that they are leaving the eclipse.org website.

[1] http://wiki.eclipse.org/Development_Resources#Committers_and_The_Eclipse.Org_Website

[2] http://www.eclipse.org//legal/termsofuse.php

Do I need a Contribution Questionnaire?

The Intellectual Property (IP) Due Diligence team has been getting a lot of unnecessary contribution questionnaires (CQ). The Eclipse Legal Process Poster [1] is the definitive guide to the process. The first two tracks through this process are the easiest.

Track One: If a contribution is 100% written by an existing project committer, under supervision of the Project Management Committee (PMC), contains no cryptography, was 100% developed from scratch, and is 100% EPL [2], then you don't need a CQ.

Track Two: Similarly, if a contribution is 100% written by employees of a company that has signed a Member Committer Agreement, under supervision of the PMC, contains no cryptography, was 100% developed from scratch, and is 100% EPL, then you also don't need a CQ;

If either of these scenarios are true, then your contribution does not require a CQ and can be committed directly into the project's source code repository. An entry in your project's IP Log is required.

The definition of "under supervision of the PMC" bears some scrutiny. At a minimum, for a contribution to meet this criteria, at least one of the existing project committers must have been involved with the development of the contribution from its inception and the contribution must provide functionality that is within the project's scope. Further, the community at large must have been given reasonable notification that the contribution was under development. Notification can take the form of discussion in a project mailing list, newsgroup, Bugzilla record, or project plan.

Your PMC may have additional requirements in their definition of "supervision"; if you have any questions, ask your PMC. If you're not sure if your contribution qualifies for either of these first two tracks, ask your PMC for help. If you're still not sure, file the CQ anyway.

[1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf

[2] http://www.eclipse.org/org/documents/epl-v10.php

Component == Project

Recent changes to the development process [1] have formalized the notion of arbitrarily nested projects, otherwise known as sub-projects. One of the implications of this change is that the former notion of a component effectively no longer exists. What we formerly referred to as a "component" is now just a sub-project. Sub-projects have their own set of committers (i.e. the source tree in the project's code repository has its own UNIX group describing who has commit privileges), their own release schedule, their own website, and more. Creation of a new sub-project requires a project proposal, followed by a creation review, and project provisioning.

The development process describes a project that itself has no sub-projects as an "Operating Project" and states that an Operating Project owns and maintains a collection of source code and/or web pages. A project that does have sub-projects, is described as a "Container Project"; Container Projects may have their own web pages, but do not have their own code repository. Effectively, this means that you can only have code in the leaf nodes of the project tree.

[1] http://www.eclipse.org/projects/dev_process/development_process.php#4_Structure_and_Organization

Back to the top