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.
Difference between revisions of "Technology"
(→Committer Elections) |
|||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Eclipse Technology Project]] | ||
This is a landing page for the [http://www.eclipse.org/technology Technology Project]. | This is a landing page for the [http://www.eclipse.org/technology Technology Project]. | ||
| Line 4: | Line 5: | ||
* [[:Category:Eclipse Technology Project | Eclipse Technology Project Category]] | * [[:Category:Eclipse Technology Project | Eclipse Technology Project Category]] | ||
* [[Technology/Project Reviews | Project Reviews]] | * [[Technology/Project Reviews | Project Reviews]] | ||
| + | * Presentation: [[Technology/Ten Eclipse Projects You Haven't Heard Enough About]] | ||
| + | |||
| + | ==What do we expect from Technology Projects== | ||
| + | |||
| + | ===Committer Elections=== | ||
| + | The trust of the existing committers is key. The fact that someone has been nominated on and vote for by the existing committers is a strong endorsement. But there is a fly in the ointment: many Eclipse projects are lacking sufficient diversity. Historically, a big part of the reason why we have pushed so hard for demonstrable contributions prior to a vote was to mitigate the risk that someone was being added to an Eclipse project simply because they've been hired or transferred at the company driving an Eclipse project. Such scenarios fly in the face of the meritocracy that we are trying to create within Eclipse projects. | ||
| + | |||
| + | The Technology PMC requires that all committer nominations include ''specific'' rationalization of the merit of the individual. At a ''minimum'', we expect that all committer nominations include a list of bugs (including ids) that the candidate has contributed patches to, and that those patches have been accepted (committed) by an existing committer. Other acceptable types of rationalization evidence include, but are not limited to: | ||
| + | |||
| + | * ''Specific'' project mailing list participation examples (for example, cases where the nominee has made specific architectural, design, or implementation contributions). | ||
| + | * Unique enhancement requests entered into Bugzilla that become committed features (whether implemented by the nominee or not). | ||
| + | * Newsgroup postings that demonstrate a depth of understanding about the project beyond the typical user. | ||
| + | * Demonstrable previous and ongoing participation in the case of a mature project being moved to Eclipse. | ||
| + | |||
| + | No one of these things is necessary or sufficient; nominees must exhibit a "body of work" to justify committer status. While support from the existing committers is obviously necessary, it is not sufficient by itself. | ||
==What does the Technology Project Management Committee (PMC) Do?== | ==What does the Technology Project Management Committee (PMC) Do?== | ||
| + | We don't do any regular calls. Most of our interaction is through the [https://dev.eclipse.org/mailman/listinfo/technology-pmc technology-pmc mailing list] as this provides a totally [http://dev.eclipse.org/mhonarc/lists/technology-pmc/maillist.html open transparent record] of our interactions. We schedule calls only on an as-needed basis to discuss topics that are either too difficult or too sensitive to discuss via email. The [http://www.eclipse.org/technology/pmc-minutes.php minutes] for all calls are posted on the website. We only schedule face-to-face meetings when it is convenient for all members (i.e. no extra travel). | ||
===Approve Intellectual Property (IP) Contribution Questionnaires (CQ)=== | ===Approve Intellectual Property (IP) Contribution Questionnaires (CQ)=== | ||
| Line 14: | Line 31: | ||
*Check that code provided by an Eclipse committer conforms to the [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf Eclipse IP Policy] (the short version of the [http://www.eclipse.org/legal/guidetolegaldoc2.php guidelines for developers] is helpful in this regard). | *Check that code provided by an Eclipse committer conforms to the [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf Eclipse IP Policy] (the short version of the [http://www.eclipse.org/legal/guidetolegaldoc2.php guidelines for developers] is helpful in this regard). | ||
**In particular, we check that the code has proper [http://www.eclipse.org/legal/copyrightandlicensenotice.php copyright and license notices]. | **In particular, we check that the code has proper [http://www.eclipse.org/legal/copyrightandlicensenotice.php copyright and license notices]. | ||
| − | *Try to reduce bloat, challenge the submitter to use alternative similar technology | + | *Try to reduce bloat, challenge the submitter to use alternative similar technology already available. |
===Approve New Committers=== | ===Approve New Committers=== | ||
| Line 28: | Line 45: | ||
===Help Projects Develop a Community=== | ===Help Projects Develop a Community=== | ||
Most of the work here falls more into the category of "teaching a committer to fish". We don't develop the community for a project, we encourage the project to do the sorts of things that need to be done to develop a community. We will blog or deliver presentations about a project when an opportunity presents itself. | Most of the work here falls more into the category of "teaching a committer to fish". We don't develop the community for a project, we encourage the project to do the sorts of things that need to be done to develop a community. We will blog or deliver presentations about a project when an opportunity presents itself. | ||
| + | |||
| + | As part of this effort, we encourage projects to actively participate in the Eclipse community. This involves aggregating blogs on [http://planet.eclipse.org/planet Planet Eclipse], forging links with other projects, and leveraging existing technology (rather than inventing new). | ||
===Review Projects on an Ongoing Basis=== | ===Review Projects on an Ongoing Basis=== | ||
| − | We periodically review projects to ensure that they're doing the right sorts of things to progress. We ensure, for example, that projects are making reasonable effort to develop community. We ensure that they're following the Eclipse IP Policy. | + | We periodically review projects to ensure that they're doing the right sorts of things to progress. We ensure, for example, that projects are making reasonable effort to develop community. We ensure that they're following the Eclipse IP Policy. [[Technology/Project reviews | Project Reviews]] are documented. |
===Help Technology Projects to Stop being Technology Projects=== | ===Help Technology Projects to Stop being Technology Projects=== | ||
Some Technology projects just go on forever. And this fine for projects of a research nature. However, over time, projects will mature and a more appropriate permanent home may need to be identified (e.g. a different top-level project). Alternatively, some projects run their course and reach a natural end. We help these projects terminate as gracefully as possible. | Some Technology projects just go on forever. And this fine for projects of a research nature. However, over time, projects will mature and a more appropriate permanent home may need to be identified (e.g. a different top-level project). Alternatively, some projects run their course and reach a natural end. We help these projects terminate as gracefully as possible. | ||
Latest revision as of 17:28, 6 September 2011
This is a landing page for the Technology Project.
Contents
- 1 Useful Links
- 2 What do we expect from Technology Projects
- 3 What does the Technology Project Management Committee (PMC) Do?
- 3.1 Approve Intellectual Property (IP) Contribution Questionnaires (CQ)
- 3.2 Approve New Committers
- 3.3 Find New Projects
- 3.4 Help New Projects with their Proposals
- 3.5 Help Projects Develop a Community
- 3.6 Review Projects on an Ongoing Basis
- 3.7 Help Technology Projects to Stop being Technology Projects
Useful Links
- Eclipse Technology Project Category
- Project Reviews
- Presentation: Technology/Ten Eclipse Projects You Haven't Heard Enough About
What do we expect from Technology Projects
Committer Elections
The trust of the existing committers is key. The fact that someone has been nominated on and vote for by the existing committers is a strong endorsement. But there is a fly in the ointment: many Eclipse projects are lacking sufficient diversity. Historically, a big part of the reason why we have pushed so hard for demonstrable contributions prior to a vote was to mitigate the risk that someone was being added to an Eclipse project simply because they've been hired or transferred at the company driving an Eclipse project. Such scenarios fly in the face of the meritocracy that we are trying to create within Eclipse projects.
The Technology PMC requires that all committer nominations include specific rationalization of the merit of the individual. At a minimum, we expect that all committer nominations include a list of bugs (including ids) that the candidate has contributed patches to, and that those patches have been accepted (committed) by an existing committer. Other acceptable types of rationalization evidence include, but are not limited to:
- Specific project mailing list participation examples (for example, cases where the nominee has made specific architectural, design, or implementation contributions).
- Unique enhancement requests entered into Bugzilla that become committed features (whether implemented by the nominee or not).
- Newsgroup postings that demonstrate a depth of understanding about the project beyond the typical user.
- Demonstrable previous and ongoing participation in the case of a mature project being moved to Eclipse.
No one of these things is necessary or sufficient; nominees must exhibit a "body of work" to justify committer status. While support from the existing committers is obviously necessary, it is not sufficient by itself.
What does the Technology Project Management Committee (PMC) Do?
We don't do any regular calls. Most of our interaction is through the technology-pmc mailing list as this provides a totally open transparent record of our interactions. We schedule calls only on an as-needed basis to discuss topics that are either too difficult or too sensitive to discuss via email. The minutes for all calls are posted on the website. We only schedule face-to-face meetings when it is convenient for all members (i.e. no extra travel).
Approve Intellectual Property (IP) Contribution Questionnaires (CQ)
When projects take contributions and make use of third-party libraries, they are required to enter a CQ. A CQ will not be processed by the IP team until it has been approved by the PMC. When we are informed of a new CQ (via email), we do the following:
- An initial license check
- Check that code provided by an Eclipse committer conforms to the Eclipse IP Policy (the short version of the guidelines for developers is helpful in this regard).
- In particular, we check that the code has proper copyright and license notices.
- Try to reduce bloat, challenge the submitter to use alternative similar technology already available.
Approve New Committers
When a project's committer election has completed, we give the final approval.
Find New Projects
We identify new project opportunities and invite interesting work to become Eclipse Technology Projects.
Help New Projects with their Proposals
All new Eclipse projects start with a proposal. We guide new projects get through the proposal process by (a) helping them assemble the proposal document, and (b) attend the creation review call with them. As part of assembling the proposal document, we will aid a new project in identifying Architecture Council mentors and "Interested Parties".
Help Projects Develop a Community
Most of the work here falls more into the category of "teaching a committer to fish". We don't develop the community for a project, we encourage the project to do the sorts of things that need to be done to develop a community. We will blog or deliver presentations about a project when an opportunity presents itself.
As part of this effort, we encourage projects to actively participate in the Eclipse community. This involves aggregating blogs on Planet Eclipse, forging links with other projects, and leveraging existing technology (rather than inventing new).
Review Projects on an Ongoing Basis
We periodically review projects to ensure that they're doing the right sorts of things to progress. We ensure, for example, that projects are making reasonable effort to develop community. We ensure that they're following the Eclipse IP Policy. Project Reviews are documented.
Help Technology Projects to Stop being Technology Projects
Some Technology projects just go on forever. And this fine for projects of a research nature. However, over time, projects will mature and a more appropriate permanent home may need to be identified (e.g. a different top-level project). Alternatively, some projects run their course and reach a natural end. We help these projects terminate as gracefully as possible.