org.eclipse.dash.handbook issueshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues2020-11-25T19:34:02Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/40Add a branding checklist to the handbook2020-11-25T19:34:02ZEclipse WebmasterAdd a branding checklist to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#505741)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505741)**
## Description
e.g.
- Project web site must be hosted at eclipse.org
- First reference to project na...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#505741)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505741)**
## Description
e.g.
- Project web site must be hosted at eclipse.org
- First reference to project name needs to be Eclipse `<project name>`
- Project web site needs to include the standard Eclipse footer
### Blocking
* [Bug 485704](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485704)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/92Add a code of conduct to the legal documentation2020-11-25T19:36:02ZEclipse WebmasterAdd a code of conduct to the legal documentation## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#528741)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=528741)**
## Description
Consider adding a code of conduct document to the legal document requirements.
https:...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#528741)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=528741)**
## Description
Consider adding a code of conduct document to the legal document requirements.
https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/128Add advice regarding releasing parts of a project2020-11-25T19:37:17ZEclipse WebmasterAdd advice regarding releasing parts of a project## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#544297)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=544297)**
## Description
It's relatively rare, but some projects need to release parts of their project. Projec...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#544297)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=544297)**
## Description
It's relatively rare, but some projects need to release parts of their project. Projects that make a habit of this sort of behaviour should probably consider refactoring (i.e. if you're releasing components on different schedules, should those components be separate projects?).
Here's part of an email that I sent to a committer.
--
To do a formal release, you need to first create a release record. You can put arbitrary text into the release name, so you could, for example, call a release "glassfish-doc-plugin 1.0" and then engage in the release process with that. The only real challenge in this is to ensure that it doesn't confuse the community or the development team.
Note that we made a change to the EDP in December that lets a project push out releases for a year after engaging in a successful Release or Progress Review. So you don't actually need to submit an IP Log for review or engage in a Release Review. Just create the release record and push out your bits. Any IP reviews associated with the content that you're pushing out need to be fully resolved before you push out anything that is considered an official release.
FWIW, you can also just build and push the new content to Maven labeled as a "milestone" build (or "alpha", "beta", "SNAPSHOT", whatever) of the forthcoming Eclipse GlassFish 5.2 release (e.g. set the version of the Maven record to "5.2M1" or something).
From a process point-of-view, you could also create an "Eclipse GlassFish 5.1.1" release that includes all of the exact same versions of software Eclipse GlassFish 5.1 has plus this plug-in. There's no rule that says that you have to rebuild everything, or that every software component share the same version as the associated Eclipse Project release (for example, the Eclipse IDE project only builds new versions of their plug-ins that actually change; "Eclipse IDE 4.10" includes plug-ins with a very wide range of version numbers). Again, it's really all about managing community confusion.
--
Eclipse MicroProfile also does this, so there might be an opportunity to scavenge some text from email exchanges with that team.
--https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/41Add an appendix specifically concerned with issues related to extending the E...2020-11-25T19:34:07ZEclipse WebmasterAdd an appendix specifically concerned with issues related to extending the Eclipse Platform## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#505925)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505925)**
## Description
I think that it would be a handy addition to the Eclipse Project Handbook (and perhaps...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#505925)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505925)**
## Description
I think that it would be a handy addition to the Eclipse Project Handbook (and perhaps the PolarSys variant) with helpful hints for building Eclipse Plug-ins, etc.
e.g.
* notice file requirements;
* recommendations for logging, preferences, namespaces, etc.
* use of Package-Import vs. Bundle-Require
Much of this information is already in the wiki.
### Depends on
* [Bug 505924](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505924)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/29Add a "New Committer Orientation" section to the handbook2020-11-25T19:33:33ZEclipse WebmasterAdd a "New Committer Orientation" section to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#496029)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496029)**
## Description
Provide a concise overview of what new committers need to know with pointers into the ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#496029)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496029)**
## Description
Provide a concise overview of what new committers need to know with pointers into the documentation.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/53Add an Intellectual Property FAQ entry regarding whether or not an IP Log nee...2020-11-25T19:34:39ZEclipse WebmasterAdd an Intellectual Property FAQ entry regarding whether or not an IP Log needs to be respun## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#509610)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=509610)**
## Description
There is some confusion regarding whether or not a project team needs to respin an IP ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#509610)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=509610)**
## Description
There is some confusion regarding whether or not a project team needs to respin an IP Log if they make a change between the time the IP log is approved and they actually ship release bits.
Specifically, there is a misunderstanding that the IP Log must exactly match the IP that's in the release bits.
--
Q: We submitted an IP Log for our release, but we've made some changes since then that will end up in the release, should we resubmit the IP Log?
A: The purpose of the IP Log review is to checkpoint the IP Due Diligence Process and ensure that nothing is slipping through the cracks; an IP Log is not intended to be an accurate reflection of exactly what is in any particular release.
--
### Blocking
* [Bug 499707](https://bugs.eclipse.org/bugs/show_bug.cgi?id=499707)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/51Add a pointer to the IP Log Generator in the "IP Log Generator" section2020-11-25T19:34:31ZEclipse WebmasterAdd a pointer to the IP Log Generator in the "IP Log Generator" section## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#509114)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=509114)**
## Description
We do have a pointer (instructions, actually) to the IP Log Generator in the "Release ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#509114)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=509114)**
## Description
We do have a pointer (instructions, actually) to the IP Log Generator in the "Release Reviews" section. It seems obvious to include that same pointer in the "IP Log Generator" section.
### Blocking
* [Bug 499707](https://bugs.eclipse.org/bugs/show_bug.cgi?id=499707)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/13Add a recommendation to use "dummy inboxes" in Bugzilla2020-11-25T19:32:54ZEclipse WebmasterAdd a recommendation to use "dummy inboxes" in Bugzilla## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485187)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485187)**
## Description
This may fit in a "community development" section.
Recommendation: use "dummy inboxes...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485187)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485187)**
## Description
This may fit in a "community development" section.
Recommendation: use "dummy inboxes" as the default assignee in Bugzilla.
By using a dummy inbox, it is easier for community members to follow Bugzilla discussion related to your project by setting a preference to be copied when that inbox is messaged.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/119Add a section that describes how to be a member of the Architecture Council2020-11-25T19:37:02ZEclipse WebmasterAdd a section that describes how to be a member of the Architecture Council## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#538428)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=538428)**
## Description
It would be handy to have some content to help Architecture Council members understand...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#538428)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=538428)**
## Description
It would be handy to have some content to help Architecture Council members understand their role.
e.g.
What does a project mentor do?
How do I become a project mentor?https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/127Add content describing how project team can receive (significant) code contri...2020-11-25T19:37:16ZEclipse WebmasterAdd content describing how project team can receive (significant) code contributions## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#543503)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=543503)**
## Description
Starting point:
--
1) Contributors make some sort of public announcement that the con...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#543503)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=543503)**
## Description
Starting point:
--
1) Contributors make some sort of public announcement that the content will be delivered to the project
2) If the source code is not already in a public repository, it will have to be delivered to an existing project committer in some way
3) The source needs to be handed off to the IP Team for their review as a "project code" contribution to an existing project
4) Any developers who are coming to the project along with the code need to be voted in as committers
5) When the IP Team gives the go-ahead, either the existing public repository needs to be moved to the Eclipse Foundation, or a new repository can be created and used as a home for the code.
--https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/35Add content regarding the use of third-party services2020-11-25T19:33:49ZEclipse WebmasterAdd content regarding the use of third-party services## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#499792)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=499792)**
## Description
Projects are required to use Eclipse Foundation services for all core services. Projec...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#499792)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=499792)**
## Description
Projects are required to use Eclipse Foundation services for all core services. Project teams may want to use other services. We need to provide some guidance.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/132Add content supporting specification projects to the handbook2020-11-25T19:37:24ZEclipse WebmasterAdd content supporting specification projects to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#552040)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=552040)**
## Description
For example...
For release reviews, specification projects require a ballot of the sp...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#552040)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=552040)**
## Description
For example...
For release reviews, specification projects require a ballot of the specification committee. My current thinking is that the EMO will request that the specification committee initiate the ballot.
Project teams should also anticipate the extra time required to complete the release review. Ballots require a minimum of two weeks and may be extended to 30 days.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/143Add content to help project teams to market themselves.2020-11-25T19:37:43ZEclipse WebmasterAdd content to help project teams to market themselves.## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#567642)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=567642)**
## Description
Examples:
* Create a twitter handle (with a pointer to the social media policy)
* Tra...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#567642)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=567642)**
## Description
Examples:
* Create a twitter handle (with a pointer to the social media policy)
* Trademark management
* Leverage the Adopters Programme
* Announce releases via news@eclipse.orghttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/24Add discussion of what to expect when transitioning an existing project2024-01-15T20:35:32ZEclipse WebmasterAdd discussion of what to expect when transitioning an existing project## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#491835)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=491835)**
## Description
We need some discussion of what existing projects should expect when transitioning to ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#491835)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=491835)**
## Description
We need some discussion of what existing projects should expect when transitioning to Eclipse/LocationTech/PolarSys. This belongs in the "Starting a New Open Source Project" section.
e.g.
Projects transitioning to Eclipse are required to:
* Transfer ownership any existing project name to the EF;
* Transfer existing domain names that use the project name trademark to the EF;
* Conform to the Eclipse Logo & Trademark usage guidelines on project websites and in communication with the community (e.g. in slide decks);
* Conform to the Eclipse Development Process;
* Conform to the Eclipse IP Policy and follow the Eclipse IP Due Diligence Process;
* Maintain metadata pertaining to the project using the EF-provided PMI;
* Use EF-provided VCS for all project source code;
* Host binary distributions from EF-provided downloads server; and
* Use EF-provided web hosting services for the project's primary website.
Note that other services can be used in addition to EF-provided ones, but the EF provided ones must be considered canonical.
Projects are expected spend effort engaging with their community, and court contributions and new developers. Projects are also encouraged to provide mature automated build solutions, maintain both user and contributor documentation, and otherwise engage in activities that encourage participation in the project.
New project sponsors must engage in the process of transitioning an existing project with the intent to continue development of the project code and growth of the community and ecosystem around the project.https://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.
--