Eclipse Dash issueshttps://gitlab.eclipse.org/groups/eclipse/technology/dash/-/issues2020-11-25T19:35:04Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/65[faq] How do we transfer committers from one project to another?2020-11-25T19:35:04ZEclipse Webmaster[faq] How do we transfer committers from one project to another?## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514713)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514713)**
## Description
Add a FAQ entry to the Elections section. Short answer: you don't
We have no concept ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514713)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514713)**
## Description
Add a FAQ entry to the Elections section. Short answer: you don't
We have no concept of transferring committers. if committers need to move from one project to another, then they should be elected as committers to the new project and retire themselves from the old one.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/66Describe how project websites work2020-11-25T19:35:06ZEclipse WebmasterDescribe how project websites work## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514813)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514813)**
## Description
We don't describe how project websites work.
--
Every project gets its own website Gi...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514813)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514813)**
## Description
We don't describe how project websites work.
--
Every project gets its own website Git repository for which all project committers have push access. A scripts polls the website Git repository for changes and automatically propagates them to the site. Anything that you push to the master branch just shows up on the website after about a minute.
--
Consider consolidating separate related sections
https://www.eclipse.org/projects/handbook/#resources-website
https://www.eclipse.org/projects/handbook/#trademarks-website
https://www.eclipse.org/projects/handbook/#development-websitehttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/67Add help for setting due diligence type in the PMI2020-11-25T19:35:08ZEclipse WebmasterAdd help for setting due diligence type in the PMI## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#516823)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=516823)**
## Description
Project teams can decide the type of IP Due Diligence that their project employs both ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#516823)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=516823)**
## Description
Project teams can decide the type of IP Due Diligence that their project employs both as a default for the project and on a release-by-release basis. Setting this field provides a valuable indicator to the project's community, and serves as input into some of our processes (e.g. contribution questionnaire creation).
Any committer can set the due diligence type for a project or a release. To set the due diligence type, visit the project or release page in the PMI and click "Edit". Expand the section titled "The Basics" and scroll down to the "IP Due Diligence Type" field. Set the value there.
Note that the value will only be displayed if it is explicitly set on the project or record. Eclipse Foundation processes that use this information will default to the value specified in the project record if the field is not explicitly set on the release. If the field is not set on the project record, Type B is assumed.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/68[faq] Can a contributor use "@users.noreply.github.com" as an e-mail address?2020-11-25T19:35:11ZEclipse Webmaster[faq] Can a contributor use "@users.noreply.github.com" as an e-mail address?## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517749)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517749)**
## Description
/cc Chris as there may be an opportunity to catch this as part of account management.
...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517749)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517749)**
## Description
/cc Chris as there may be an opportunity to catch this as part of account management.
If I understand correctly how this works [1], the answer has to be no.
Contributing to an open source project is a transparent process. We need to be able to trace contributions back to a specific individual.
The first important question is whether or not my understanding is correct. Is there actual traceability from a commit that uses this sort of email address? Can we actually contact somebody via this email address?
https://help.github.com/articles/keeping-your-email-address-private/
### Blocking
* [Bug 485964](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485964)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/69[glossary] Add Long Term Support (LTS)2020-11-25T19:35:14ZEclipse Webmaster[glossary] Add Long Term Support (LTS)## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517753)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517753)**
## Description
Add a glossary entry for Long Term Support.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517753)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517753)**
## Description
Add a glossary entry for Long Term Support.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/70Add discussion regarding naming milestones and release candidates2020-11-25T19:35:16ZEclipse WebmasterAdd discussion regarding naming milestones and release candidates## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517754)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517754)**
## Description
Note that this is more of a convention and best practice than a rule.
In terms of the...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#517754)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517754)**
## Description
Note that this is more of a convention and best practice than a rule.
In terms of the simultaneous release, I've explained it (in part) as such:
--
The simultaneous release has several builds throughout the year. The first seven are milestone builds, denoted M1..M7. Then there are three release candidate builds, denoted as RC1..RC2. Since some projects depend on other projects, each build is staggered into stages (projects in stage 2 depend on projects in stage 1, etc). Stages are denoted as some number of days after we start the build, i.e. +0..+3. So... RC1+0 is the first stage for the first release candidate, RC1+1 is the next day, etc.
--
We can probably harvest some content from the simultaneous release. The Eclipse Project likely also has some relevant content and there is likely other content in the wiki that can help.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/71Add discussion regarding available services (e.g. builds, Sonar) including SLA2020-11-25T19:35:18ZEclipse WebmasterAdd discussion regarding available services (e.g. builds, Sonar) including SLA## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#518974)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=518974)**
## Description
Let's consider adding some discussion (or update the existing discussion) regarding se...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#518974)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=518974)**
## Description
Let's consider adding some discussion (or update the existing discussion) regarding services and be sure to make explicit the service levels.
https://wiki.eclipse.org/IT_SLA
Let's be careful, here, about duplicating any information. If the right home for this information is in the wiki (maintained by the webmaster), then the handbook should provide a pointer with some text that at least indicates that there are different tiers of service.
While we're at it, we should likely include an indication of SLA in wiki entries.
e.g. the Developer Resources page includes a link to Sonar support; both that page and the Sonar page itself should explicitly state the service tier and what that means.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/72Move "Becoming a Committer" content into the handbook2020-11-25T19:35:20ZEclipse WebmasterMove "Becoming a Committer" content into the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#519230)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519230)**
## Description
https://wiki.eclipse.org/Development_Resources/Becoming_a_Committer## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#519230)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519230)**
## Description
https://wiki.eclipse.org/Development_Resources/Becoming_a_Committerhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/73Add discussion regarding milestone builds and service releases2020-11-25T19:35:21ZEclipse WebmasterAdd discussion regarding milestone builds and service releases## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#519320)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519320)**
## Description
The handbook lacks discussion nightly/integration/milestone builds. While these notion...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#519320)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519320)**
## Description
The handbook lacks discussion nightly/integration/milestone builds. While these notions are discussed in the EDP, we have an opportunity to more fully define the different sorts of builds in more specific detail in the handbook, and guidance in terms of their intended audiences and distribution. At very least, we should provide pointers into the EDP. While we're at it, we should include service releases in that discussion. This all probably fits in the "Releases" section.
We should probably also add glossary entries, e.g.
* Build (with discussion of different sorts of builds)
* Milestone Build
* Integration Build
* Nightly Build
and
* Release
* Service Release
* Release Review
Some background discussion from the incubation mailing list:
--
According to the Eclipse handbook, we are supposed to follow the review process. Because we are not ready for entering the release process (from my point of view we don't have enough documentation as required in the handbook) I wanted to know if there is a possibility to provide kind of a snapshot distribution for testing purpose without entering the release process?
--
Response (thanks, Ed Merks):
--
Just do no call it a release. Don't use that word to describe what you've making available/redistributing. Of course almost all projects do nightly, integration, milestone, and release candidate builds and make those available as p2 update sites or otherwise for their consumers. You can do the same. A release review is only required to produce a release and you can do that when you feel the code is in a quality state that you feel comfortable can be represented as a stable release for your consumers.
--https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/74Include copyright and license header help in the Guide to the Legal Documenta...2020-11-25T19:35:23ZEclipse WebmasterInclude copyright and license header help in the Guide to the Legal Documentation## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520109)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520109)**
## Description
Copyright headers are part of the legal documentation. We should include them in the d...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520109)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520109)**
## Description
Copyright headers are part of the legal documentation. We should include them in the documentation along with everything else.
We'll use this opportunity to tweak our guidance. Note that we're not going to require wholesale changes to any existing headers. Rather this is for new content or for projects that are otherwise engaged in changing headers (e.g. while updating to the EPL-2.0).
Let's avoid including the actual comment framing in the discussion. e.g.
--
Copyright (c) 2017 ACME Loo, and others
This program and the accompanying materials
are made available under the terms of the Eclipse Public License
v1.0 which accompanies this distribution, and is available at
http://www.eclipse.org/legal/epl-v10.html
SPDX-License-Identifier: EPL-1.0
--
The content, embedded in an actual comment (e.g. framed top, left, and bottom with a bar of stars) may be presented as an example.
Note the inclusion of the SPDX-License-Identifier tag.
We'll use this opportunity to introduce an alternative header style:
--
Copyright (c) 2017 Contributors to the Eclipse Foundation
See the NOTICE file(s) distributed with this work for additional
information regarding copyright ownership.
This program and the accompanying materials
are made available under the terms of the EPL-1.0
which accompanies this distribution and is available at
https://www.eclipse.org/org/documents/epl-v10.html.
SPDX-License-Identifier: EPL-1.0
--
With this style, the project team is obligated to provide a list of copyright holders in a notices file.
I have some ideas for how we might help project teams automate this.
### Depends on
* [Bug 514948](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514948)
### Blocking
* [Bug 498155](https://bugs.eclipse.org/bugs/show_bug.cgi?id=498155)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/75Add instructions for board approval of logos that derive from the Eclipse logo.2021-03-24T17:24:26ZEclipse WebmasterAdd instructions for board approval of logos that derive from the Eclipse logo.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520705)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520705)**
## Description
Since the Trademark and Logo usage guidelines give very specific instructions, we prob...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520705)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520705)**
## Description
Since the Trademark and Logo usage guidelines give very specific instructions, we probably don't need to provide anything more than an FAQ entry.
https://eclipse.org/legal/logo_guidelines.phphttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/76Add information regarding using GitHub for the project website2020-11-25T19:35:27ZEclipse WebmasterAdd information regarding using GitHub for the project website## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520706)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520706)**
## Description
I believe that project teams can use GitHub to provide website content (deployed on ww...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#520706)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520706)**
## Description
I believe that project teams can use GitHub to provide website content (deployed on www.eclipse.org). We should make the instructions for requesting this and using the service as obvious as possible.
I'm pretty sure that there is documentation in the wiki (in which case a link will likely be enough), but I can't find it. Gotta link, Webmaster?
### Depends on
* [Bug 539831](https://bugs.eclipse.org/bugs/show_bug.cgi?id=539831)
### Blocking
* [Bug 485964](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485964)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/77Move proposal guidance to the handbook2020-11-25T19:35:30ZEclipse WebmasterMove proposal guidance to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#521143)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=521143)**
## Description
This is currently captured in the wiki.
https://wiki.eclipse.org/Development_Resource...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#521143)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=521143)**
## Description
This is currently captured in the wiki.
https://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phasehttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/78Make it clear that we need the author to provide their full legal name in the...2020-11-25T19:35:31ZEclipse WebmasterMake it clear that we need the author to provide their full legal name in the commit record## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522672)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522672)**
## Description
The author field must contain a valid full legal name of the contributor as well as a ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522672)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522672)**
## Description
The author field must contain a valid full legal name of the contributor as well as a real email address.
The DCO states (in part):
--
I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my signoff) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
--
Further, contributions cannot be accepted anonymously.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/79Capture policy regarding the use of Google Analytics on project pages2020-11-25T19:35:33ZEclipse WebmasterCapture policy regarding the use of Google Analytics on project pages## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522674)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522674)**
## Description
We could frame this as an example or, perhaps, as an FAQ entry in the handbook.
The g...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522674)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522674)**
## Description
We could frame this as an example or, perhaps, as an FAQ entry in the handbook.
The gist is that it's okay to use Google Analytics. We even provide instructions (Chris, can you provide me with a link to those instructions?). But the "keys must be shared" rule needs to be followed. No single individual (or organization) can own access to the configuration or data.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/80Describe the life-cycle of the bugs we create to track project creations and ...2020-11-25T19:35:36ZEclipse WebmasterDescribe the life-cycle of the bugs we create to track project creations and reviews.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522675)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522675)**
## Description
The Eclipse Projects Team creates the bug for tracking our processes; we'll close it.
...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#522675)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522675)**
## Description
The Eclipse Projects Team creates the bug for tracking our processes; we'll close it.
We keep the proposal/creation bug open until after the project has done it's first release.
Review tracking bugs are closed when the review is declared successful and activities related to the review have been completed. For release reviews, the bug is closed immediately after success is declared. For restructuring and termination reviews, we keep the bug open until the related activites (e.g. archiving a project) are complete.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/81Revise the content regarding Third Party Content2020-11-25T19:35:38ZEclipse WebmasterRevise the content regarding Third Party Content## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#525252)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=525252)**
## Description
From the incubation mailing list:
--
in the IoT PMC we often review CQs by projects fo...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#525252)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=525252)**
## Description
From the incubation mailing list:
--
in the IoT PMC we often review CQs by projects for components which the project relies on during runtime (not optionally but as a full pre-req). Some of these components themselves rely on many other components. We are often asked, whether the project needs to create CQs for all of these transitive dependencies as well (given that they are not optional but required during runtime).
The project handbook [1] states that "All third-party libraries required by project code will have to be checked and approved by the IP Team."
Following is a list of cases which constitute a "library required by the project". That list is described as "non-exhaustive" and in fact does not explicitly mention transitive dependencies. My understanding is that transitive deps definitely need to be checked/approved, but I would like to get some feedback e.g. frmo Wayne whether this is actually the case.
--
The use of "non-exhaustive" is intended to refer to the list of examples. Let's check the language to ensure that this intended usage is clear. We should make it clear that the policy applies to the transitive closure of all dependencies.
There may be some useful words in my response:
--
All content must be taken through the Eclipse IP Due Diligence Process. This includes all dependencies, dependencies of dependencies, etc. [recursive].
FWIW, the operating system and virtual machine are technically dependencies, but we classify them "exempt pre-reqs" per the Guidelines for the Review of Third Party Dependencies (implied, because we don't bother with actual CQs).
This is easy to think about in the context of a monolithic packaged deliverable. Basically anything that's in that hypothetical monolithic package must be taken through the Eclipse IP Due Diligence Process.
It's a little harder to think about when you distribute, say, a Maven JAR. Strictly speaking, you are only distributing that one JAR. But in the process of resolving that JAR, the consumer will need all sorts of other third party content; this content is all "pre-req dependencies" that we need the Eclipse IP Team to review.
Perhaps the most general way of thinking about it is that you need a CQ for all third party content related to your project code that will end up in a product built using your project's technology. It's on this basis that we can, for example, categorize build and test dependencies as "works with". I suspect, however, that I'm venturing off topic...
--https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/82Update legal documentation requirements for Eclipse Platform Features and Plu...2020-11-25T19:35:40ZEclipse WebmasterUpdate legal documentation requirements for Eclipse Platform Features and Plug-ins## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#525401)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=525401)**
## Description
I've taken a first pass at documenting legal document requirements for Eclipse Plug-in...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#525401)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=525401)**
## Description
I've taken a first pass at documenting legal document requirements for Eclipse Plug-ins and Fragements [1], starting from the original documentation [2].
With the adoption of the EPL-2.0, we've decided to do away with the SUA. The actual license text can be used in its place for most content. In most cases, this is pretty straightforward and should require no more work than would be required to replace content with an updated SUA. It gets a little weird with Feature Update Licenses which require that the union of licenses in the corresponding plug-ins also be listed.
I've created this bug as a focal point for discussion regarding the content. The exist content is marked as a draft. I'll close this bug after we've decided to remove that mark.
[1] http://www.eclipse.org/projects/handbook#legaldoc-plugins
[2] http://www.eclipse.org/legal/guidetolegaldoc-EPL-1.0.php
### Blocking
* [Bug 519789](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519789)
* [Bug 522264](https://bugs.eclipse.org/bugs/show_bug.cgi?id=522264)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/83Move Build and Test Dependencies content to the handbook2020-11-25T19:35:43ZEclipse WebmasterMove Build and Test Dependencies content to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526057)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526057)**
## Description
Move this content into the handbook.
https://wiki.eclipse.org/Development_Resources/I...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526057)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526057)**
## Description
Move this content into the handbook.
https://wiki.eclipse.org/Development_Resources/IP/Test_and_Build_Dependencieshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/85[faq] Do bundle versions have to match the release version?2020-11-25T19:35:48ZEclipse Webmaster[faq] Do bundle versions have to match the release version?## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526174)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526174)**
## Description
No.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526174)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526174)**
## Description
No.