org.eclipse.dash.handbook issueshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues2020-11-25T19:32:57Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/14Add discussion on naming companies on project resources2020-11-25T19:32:57ZEclipse WebmasterAdd discussion on naming companies on project resources## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485283)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485283)**
## Description
There are cases where it may be desirable to mention a company name. Can we, for examp...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485283)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485283)**
## Description
There are cases where it may be desirable to mention a company name. Can we, for example, indicate in review documentation that a particular company funded the development of a particular feature?
We have a board directive that describes the conditions under which a company logo can be displayed.
* The company must be a member of the Eclipse Foundation;
* At least one committer has to be listed as an employee of the company in question;
* The committer must be on this project; and
* The committer must be active (must have made at least one commit in the last three months).
### Blocking
* [Bug 485446](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485446)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/42Add discussion on the relationship between GitHub releases and EDP releases t...2020-11-25T19:34:08ZEclipse WebmasterAdd discussion on the relationship between GitHub releases and EDP releases to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#506836)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=506836)**
## Description
An excerpt from a recent email that I sent:
--
We've avoided adding any significance ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#506836)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=506836)**
## Description
An excerpt from a recent email that I sent:
--
We've avoided adding any significance (as far as the Eclipse Development Process is concerned) to GitHub "releases". Though, I am concerned that there is ample opportunity for confusion between the GitHub notion and the more formal notion that we engage in. If you do choose to use GitHub releases as a concept separate from the EDP, I'd prefer that you use names that are suggestive of milestones (e.g. 1.0M1 is a milestone build for a pending more formal 1.0 release).
--
### 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/12Add discussion on trademarks2020-11-25T19:32:52ZEclipse WebmasterAdd discussion on trademarks## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#484595)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=484595)**
## Description
The Eclipse legal staff takes on the responsibility of reviewing trademarks (e.g. proj...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#484595)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=484595)**
## Description
The Eclipse legal staff takes on the responsibility of reviewing trademarks (e.g. project names). To speed things up, it would be good to help the project team select good names that have at least some chance of passing review.
There are some simple things that project teams can do, like search Google for "`<term>` software" and see what comes up.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/20Add discussion regarding a CONTRIBUTING(.md)? file2020-11-25T19:33:13ZEclipse WebmasterAdd discussion regarding a CONTRIBUTING(.md)? file## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487547)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487547)**
## Description
Base the content on this:
https://wiki.eclipse.org/Architecture_Council/Contributor_G...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487547)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487547)**
## Description
Base the content on this:
https://wiki.eclipse.org/Architecture_Council/Contributor_Guide_Recommendationhttps://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/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/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/8Add discussion regarding project independence2020-11-25T19:32:44ZEclipse WebmasterAdd discussion regarding project independence## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#482412)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482412)**
## Description
Apache does a good job of this:
http://community.apache.org/projectIndependence## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#482412)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482412)**
## Description
Apache does a good job of this:
http://community.apache.org/projectIndependencehttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/118Add discussion regarding trademarks to the "Starting an Open Source Project a...2024-01-15T20:35:32ZEclipse WebmasterAdd discussion regarding trademarks to the "Starting an Open Source Project at Eclipse Foundation" section## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#537997)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=537997)**
## Description
We do have some discussion regarding trademarks in the document (e.g. [1]) and the "St...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#537997)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=537997)**
## Description
We do have some discussion regarding trademarks in the document (e.g. [1]) and the "Starting an Open..." section [2] does touch on the subject, but more detail will be valuable.
We should, for example, describe the trademark review and transfer process, offer some specific guidance regarding how to select a name, and ensure that the reader is aware that they will need to sign related domain names to the Eclipse Foundation.
It might be valuable to talk about expectations regarding technical namespaces (e.g. that projects should use "org.eclipse.*" for their Java namespace when technically feasible).
[1] https://www.eclipse.org/projects/handbook/#trademarks
[2] https://www.eclipse.org/projects/handbook/#startinghttps://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 resourceshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/26Add documentation for the new IP Log Generator2020-11-25T19:33:26ZEclipse WebmasterAdd documentation for the new IP Log Generator## Submitted by Ed Willink
**[Link to original bug (#493967)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=493967)**
## Description
The tool directs to:
https://wiki.eclipse.org/PMI/IP_Log_Generator
in the generated title:
The I...## Submitted by Ed Willink
**[Link to original bug (#493967)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=493967)**
## Description
The tool directs to:
https://wiki.eclipse.org/PMI/IP_Log_Generator
in the generated title:
The IP Log Generator gathers information from several sources. For more information on those sources and how to change values in this generated log, please see The IP Log Generator in the wiki. Note that this preview can only be accessed by project team members.
the referenced page is a dummy, so how to change?https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/28Add documentation to describe including multiple subprojects with a release2020-11-25T19:33:31ZEclipse WebmasterAdd documentation to describe including multiple subprojects with a release## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#495692)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=495692)**
## Description
When a project chooses to include subprojects with a release, we have a means of captu...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#495692)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=495692)**
## Description
When a project chooses to include subprojects with a release, we have a means of capturing that in the release record. This information is used currently as a hint to the IP Log generator to include those subprojects when it generates.
We should provide documentation of this in both the section on using the PMI to capture release information and as a FAQ entry in the IP Log generator section.
This impacts relatively few projects (Eclipse, Data Tools, Mylyn, and Web Tools), but is still important information.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/171Add documention about OtterDog2023-05-30T19:09:18ZMikaƫl BarberoAdd documention about OtterDogGood start at what it provides https://www.eclipse.org/lists/tractusx-dev/msg00134.htmlGood start at what it provides https://www.eclipse.org/lists/tractusx-dev/msg00134.htmlMarta RybczynskaThomas NeidhartMarta Rybczynskahttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/36Add FAQ regarding multiple Git repositories2020-11-25T19:33:51ZEclipse WebmasterAdd FAQ regarding multiple Git repositories## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#500425)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=500425)**
## Description
Projects can have more than one repository. How many is a bit of an "it depends" sort ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#500425)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=500425)**
## Description
Projects can have more than one repository. How many is a bit of an "it depends" sort of question. If they host on an EF-maintained Git server, they can create as many repositories as they'd like. If they host on GitHub, the webmaster has to create the repositories on their behalf and since this is time consuming, we look to a project team to "be reasonable".
We probably should add some sort of advice regarding "right sizing" repositories as well.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/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/106Add handbook content (FAQ?) to help committers get set up with GitHub2020-11-25T19:36:33ZEclipse WebmasterAdd handbook content (FAQ?) to help committers get set up with GitHub## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#532736)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=532736)**
## Description
I believe that the short answer is that committers need to provide their GitHub ID in ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#532736)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=532736)**
## Description
I believe that the short answer is that committers need to provide their GitHub ID in their account and magic happens.
Matt, is there any more to this?
I think that this is directly related to content regarding EF Accounts, so I've added this as a blocker of [Bug 529033](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529033).
### Blocking
* [Bug 529033](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529033)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/32Add help for committers to determine whether or not a CQ is required for proj...2020-11-25T19:33:41ZEclipse WebmasterAdd help for committers to determine whether or not a CQ is required for project code## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#497519)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=497519)**
## Description
We do have help for third-party libraries [1].
My primary concern with adding more he...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#497519)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=497519)**
## Description
We do have help for third-party libraries [1].
My primary concern with adding more help for project code contributions is that I believe that this is reasonably well covered by the IP Due Diligence document. Any attempt to duplicate that information must carefully avoid adding confusion or falling out synch.
[1] 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/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.