Eclipse Dash issueshttps://gitlab.eclipse.org/groups/eclipse/technology/dash/-/issues2021-03-24T17:24:26Zhttps://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/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/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/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/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/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/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/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/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/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/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/64Consider creating a handbook for PMCs2020-11-25T19:35:02ZEclipse WebmasterConsider creating a handbook for PMCs## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514657)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514657)**
## Description
There are various processes that the PMCs engage in that are not well documented. We s...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#514657)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514657)**
## Description
There are various processes that the PMCs engage in that are not well documented. We should consider either adding content (e.g. [Bug 508160](https://bugs.eclipse.org/bugs/show_bug.cgi?id=508160)) to the existing handbook, or creating an entirely separate handbook for PMC members.
### Depends on
* [Bug 508160](https://bugs.eclipse.org/bugs/show_bug.cgi?id=508160)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/63[nit] Use the term "third party content" instead of "third party library2021-03-24T17:25:49ZEclipse Webmaster[nit] Use the term "third party content" instead of "third party library## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#513468)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=513468)**
## Description## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#513468)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=513468)**
## Descriptionhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/62Add guidance regarding tracking requirements for service releases of third pa...2020-11-25T19:34:58ZEclipse WebmasterAdd guidance regarding tracking requirements for service releases of third party content## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#513467)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=513467)**
## Description
During the Eclipse Foundation's Board of Directors meeting in June 2015 [1], the follo...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#513467)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=513467)**
## Description
During the Eclipse Foundation's Board of Directors meeting in June 2015 [1], the following resolution was passed:
RESOLVED, that previously approved dependencies of Eclipse projects can be
reviewed and approved by the EMO as follows:
a) Service releases (e.g. x.y.*, bug fixes, security fixes) will require no review.
b) Minor revisions (e.g. x.*.*) will require a reduced review by the EMO.
c) Major revisions (e.g. *.*.*) will require a full review by the EMO.
At the time the resolution was passed, we decided to interpret this as still requiring that the project team create CQs for service releases that the IP Team approve without (significant) scrutiny. After some reflection, we're dubious of the value of having a CQ for service releases and have decided that--for pure bug-fix-only "service releases"--no CQ is required.
Some thoughts:
* This only applies for bug-fix releases that follow a minor release that's been approved by the IP Due Diligence Process
* Onus is on the project team to determine whether or not a release qualifies.
* Only patch versions greater than what's already been approved apply.
e.g., if we assume that semantic versioning is used, and that version 4.5.0 of some third party content has been approved by the IP team, a project can assume that this approval applies to versions 4.5.1, 4.5.2, ..., 4.5.n (n>0); any new version that changes either the major or minor version, e.g. 4.6.4, must be reviewed.
We need to update the documentation. The section on Third Party Content [2] is probably a good place for it.
[1] http://www.eclipse.org/org/foundation/boardminutes/2015_06_22_Minutes.pdf
[2] https://www.eclipse.org/projects/handbook/#ip-third-partyhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/61Add help for retiring committers2020-11-25T19:34:56ZEclipse WebmasterAdd help for retiring committers## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#512938)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=512938)**
## Description
We need to provide some content to help project leads retire committers.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#512938)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=512938)**
## Description
We need to provide some content to help project leads retire committers.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/60Consider moving the Gerrit user documentation into the committer handbook2020-11-25T19:34:54ZEclipse WebmasterConsider moving the Gerrit user documentation into the committer handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#512339)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=512339)**
## Description
I don't think that the handbook includes a link to the Gerrit documentation in the wik...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#512339)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=512339)**
## Description
I don't think that the handbook includes a link to the Gerrit documentation in the wiki:
https://wiki.eclipse.org/Gerrit
We should at least include a link.
I'd also like to consider moving the documentation into the handbook. My primary concern against doing so is that updating the handbook is somewhat more involved than updating the wiki.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/59Revise language used regarding hosting downloads2020-11-25T19:34:51ZEclipse WebmasterRevise language used regarding hosting downloads## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511789)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511789)**
## Description
For some projects, it just doesn't make sense to host downloads on Eclipse Foundation ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511789)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511789)**
## Description
For some projects, it just doesn't make sense to host downloads on Eclipse Foundation provided infrastructure. For project like Tycho for example, distribution via Maven Central is obvious and there is no value in having any sort of standard downloadable artifact.
Random thoughts:
I would like to avoid making projects host a download on EF infrastructure "just because". If there is no segment of the project's community that will benefit from having a traditional download, then there's no value in having/hosting that download.
We do have to heed the Freedom of Action principle outlined in the Eclipse Development Process. Project teams need to have a plan in place to rehost should their hosting solution become unavailable or untenable.
Any choice of where to host artifacts must permit unencumbered access for the entire community. Consumers must not need to register (for example) to obtain project artifacts.
If EF provided hosting services can reasonably be used, they must be used. If it is simply a matter of educating the community that the artifacts are available in one place rather than another, then a plan to provide that education must be in place. It is perfectly acceptable, for example, for a project to host downloads on bintray, but the primary download site must be on the EF-provided service.
Regardless of where artifacts are distributed, the project team must keep the project's "download" information current in the PMI. Project teams may optionally provide a "downloads" page that indicates the primary source of downloads along with alternatives.
Web pages that provide pointers to download information should (must?) also include a pointer to the security policy and a link to report vulnerabilities (see [Bug 496426](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496426)).
Let's be sure to add entries regarding distribution of artifacts to the release review checklist (see [Bug 485704](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485704)).
### Depends on
* [Bug 485704](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485704)
* [Bug 496426](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496426)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/58Add guidance on using DockerHub2020-11-25T19:34:49ZEclipse WebmasterAdd guidance on using DockerHub## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511489)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511489)**
## Description
We're currently engaged in some experimentation with projects using foundation-owned D...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511489)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511489)**
## Description
We're currently engaged in some experimentation with projects using foundation-owned DockerHub organizations. Once we sort out the lessons regarding how we should use those organizations, we should capture guidance in the handbook.
James and Roman, your insights are welcome.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/57Move content regarding naming conventions into the handbook2020-11-25T19:34:47ZEclipse WebmasterMove content regarding naming conventions into the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511321)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511321)**
## Description
The root of the content regarding naming is here:
https://wiki.eclipse.org/Developmen...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#511321)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511321)**
## Description
The root of the content regarding naming is here:
https://wiki.eclipse.org/Development_Conventions_and_Guidelines
### Depends on
* [Bug 288644](https://bugs.eclipse.org/bugs/show_bug.cgi?id=288644)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/56Add discussion regarding why one might consider creating a subproject2020-11-25T19:34:45ZEclipse WebmasterAdd discussion regarding why one might consider creating a subproject## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#510539)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=510539)**
## Description
Consider adding some discussion regarding the pros and cons of creating subprojects. S...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#510539)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=510539)**
## Description
Consider adding some discussion regarding the pros and cons of creating subprojects. Some thoughts:
* Subprojects are basically projects
* Project members have no intrinsic role in the matters of their subprojects
* All projects bear a maintenance/administrative burden
* Subprojects have a distinct committer list; finer-grained control over resources