org.eclipse.dash.handbook issueshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues2020-11-25T19:36:09Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/95Add section describing PMC role and responsibilities2020-11-25T19:36:09ZEclipse WebmasterAdd section describing PMC role and responsibilities## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#529388)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529388)**
## Description
Consider adding some discussion regarding the role of the PMC.
e.g. [1]
--
There are...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#529388)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529388)**
## Description
Consider adding some discussion regarding the role of the PMC.
e.g. [1]
--
There are a few reason we believe the review of the PMC is still helpful, such as:
* avoid mistakes by new/unexperienced projects
* help projects identify the proper CQ type (for distribution, pre-req, works-with, re-use)
* avoid pollution of the IP work queue with unnecessary CQs
--
More PMC responsibility [2]:
--
That's right, the PMC +1 was never intended as a legal review. It was intended as a check on the technical merits of the 3rd party library. For example is another similar library already in use, or an alternative approach possible that doesn't use the library. Does the library have a healthy community with consistent releases and responsive developers, etc. The PMC also determines the relationship of the library to the project - a hard dependency vs works-with dependency, etc. Maybe it varies across top level projects whether the PMC is actually in a position to know or care about this, and in some cases the sub-project lead is in a better position to figure this out (although I would argue in this case the sub-project lead should be on the PMC).
--
[1] https://dev.eclipse.org/mhonarc/lists/incubation/msg00034.html
[2] https://dev.eclipse.org/mhonarc/lists/incubation/msg00033.html
### Depends on
* [Bug 500451](https://bugs.eclipse.org/bugs/show_bug.cgi?id=500451)
* [Bug 508160](https://bugs.eclipse.org/bugs/show_bug.cgi?id=508160)
* [Bug 534264](https://bugs.eclipse.org/bugs/show_bug.cgi?id=534264)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/94Add information regarding Eclipse Foundation Accounts to the handbook2020-11-25T19:36:06ZEclipse WebmasterAdd information regarding Eclipse Foundation Accounts to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#529033)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529033)**
## Description
We should provide at least some high-level information and pointers regarding Eclipse ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#529033)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=529033)**
## Description
We should provide at least some high-level information and pointers regarding Eclipse Foundation Accounts, including discussion of things like the committer id and GitHub id (including how and where these ids are used) to the Eclipse Project Handbook. This should all be from the perspective of a committer.
Chris, do we have any of this captured anywhere?
### Depends on
* [Bug 532736](https://bugs.eclipse.org/bugs/show_bug.cgi?id=532736)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/93Move incubation content into handbook2020-11-25T19:36:04ZEclipse WebmasterMove incubation content into handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#528799)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=528799)**
## Description
Possibly related to [Bug 488421](https://bugs.eclipse.org/bugs/show_bug.cgi?id=488421)## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#528799)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=528799)**
## Description
Possibly related to [Bug 488421](https://bugs.eclipse.org/bugs/show_bug.cgi?id=488421)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/91Revise guidelines for NOTICE files in legal document guidelines2020-11-25T19:36:00ZEclipse WebmasterRevise guidelines for NOTICE files in legal document guidelines## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#527696)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527696)**
## Description
We've put some additional thought into what sort of information needs to be represente...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#527696)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527696)**
## Description
We've put some additional thought into what sort of information needs to be represented in NOTICE files. At this point, we believe that there are actually two "flavours" of notice. The primary, or "Master" notice file is located in the root of all project source code repositories, and "Distribution" notice files that are packaged in the project's distribution form (e.g. JAR files).
The "Master" notice file provides information that pertains to the _entire project_:
* Basic project metadata (name, urls, location of source, etc.);
* Description of the project's declared license(s);
* Copyright information;
* Description of third party content; and
* (when cryptographic software is present) A cryptography statement.
The "Distribution" notice files are specific to the content that they include (e.g. information that is specific to the source that produces a particular JAR file):
* Basic project metadata (as above);
* Description of the content's licensing (may be different from the project's declared license(s));
* A description of where to find the copyright information; and
* (when cryptographic software is present) A cryptography statement.
If, for example, a JAR file includes only project code, the NOTICE file would describe the project's declared license(s). If a JAR file includes only third party content, then the NOTICE file would describe the license of that third-party content. In the case where a JAR file includes a mixture of project code and third party content, the license statement would be more complex.
Note that the terms of the licenses must be observed. If a license requires that the actual text of the license be included with the distribution, then include it.
Most projects will likely have several "Distribution" notice files; it is likely that most of them will have exactly the same content. This is very similar in concept to what projects do with "about.html" files in Eclipse Platform Plug-ins.
Copyright information must be captured in the source; either in the file headers for individual source files, or in aggregate in the "Master" NOTICE file (or both).
As it would be far too onerous to do so, project teams are not required to break copyright statements into specific individual distribution artifacts. The copyright statement in a "Distribution" notice file can refer back to the "Master" notices as found in the root of the project source.
Note that we understand that this information is captured (and is generally more complete) in Git. The Git repository is a moving target: repositories move, tags get deleted or changed, we may move to different source code management system in the future, etc. The copyright information must be captured indefinitely and so must be captured in the code itself. This has the added benefit of being more readily accessible for legal review by adopters.
Note also that the copyright holder is very often not the same as the author. It is relatively easy to capture author information, but generally harder to map that to a company. The advice given to the Eclipse Foundation is that it is enough to list the authors as copyright holders (with affiliations indicated where possible).
The actual text of the project's declared license(s) is represented in a LICENSE file.
Note that the EF is working on a tool that generates at least some of this legal documentation. That tool is currently labeled as experimental and should be considered as a tool to help gather this sort of information, not a authoritative source.
e.g.
https://www.eclipse.org/projects/tools/about.php?id=technology.dash
### Blocking
* [Bug 508206](https://bugs.eclipse.org/bugs/show_bug.cgi?id=508206)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/90Include CONTRIBUTING and README to legal documents2024-01-15T20:44:46ZEclipse WebmasterInclude CONTRIBUTING and README to legal documents## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#527361)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527361)**
## Description
This is not legal documentation per se, but the legal documentation section is probabl...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#527361)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527361)**
## Description
This is not legal documentation per se, but the legal documentation section is probably the best fit.
Rough thoughts:
```
The documentation described here includes files that describe licenses and notices, as well as general information about a project and instructions for those who might choose to contribute to the project. Strictly speaking, only the files containing licenses and notices files are legal documentation; the others files are included here for completeness.
A LICENSE, NOTICE, README, and CONTRIBUTING file, as described below, must be included in the root of every source code repository.
git.eclipse.org/project.git
├── CONTRIBUTING
├── LICENSE
├── NOTICE
├── README
└── ...
[[h.ozpt2xwxudvl]]
== Contributing File
Having concise and clear information how to get involved in a project is very important for building the community around a project. Therefore, to simplify adoption and encourage contributions all project repositories must contain a contribution guide.
The contribution guide must make it very clear what are the steps a contributor needs to follow so that their contribution reaches the project and may be accepted.
* Describe the legal part of the process for accepting contributions, including a direct link to the Eclipse Contributor Agreement (ECA) and Developer Certificate of Origin (DCO);
* Provide pointers to the source code, issue trackers, communication channels, etc.
* If the project accept contributions via Gerrit, describe the mechanics of using Gerrit for the contribution;
* If the project repository is hosted on GitHub, indicate whether or not the project will accept pull requests and describe the necessary steps to have the project honor those requests; and
* Describe any further project specific rules, which the contributors should know, including preferences on code quality, code formatting, and processes for code review
Keep the guide as concise as possible - it should contain a few words and a link to the website/wiki for details and more information.
Like a license file, the contribution guide must be expressed in a human readable (plaintext) form; human readable markup languages may be used. The file is conventionally named CONTRIBUTING and may include a suffix (e.g. CONTRIBUTING.md).
[[h.2ps8v8v7gcjl]]
== “Read me” File
Adopters of the project code (e.g. those individuals and organizations who are either using the software or are incorporating it into their own products) are the target audience for a readme file.
* Landing page of the project
* Description of the project
* Pointers to the other documents (LICENSE, CONTRIBUTING, NOTICE)
* License information
* Trademark (Eclipse Foundation and project-specific trademark statements)
The file is conventionally called README and may include a suffix. The contents can either be plaintext or a markup format.
```https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/89Build the Eclipse Project Handbook as EPUB2020-11-25T19:35:56ZEclipse WebmasterBuild the Eclipse Project Handbook as EPUB## Submitted by Torkild Resheim
**[Link to original bug (#527122)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527122)**
## Description
The EPUB format is popular for publishing books to various devices. The content can be reflowe...## Submitted by Torkild Resheim
**[Link to original bug (#527122)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=527122)**
## Description
The EPUB format is popular for publishing books to various devices. The content can be reflowed to support various screen sizes and most reading systems allows for annotations and bookmarks. This makes the format suitable for user guides and reference manuals such as the "Eclipse Project Handbook".
There are several ways of generating an EPUB from HTML. One method would be to use the Asciidoctor EPUB[1] output. This is an ambitious project that also offers Kindle output format. However, it is still in alpha stage and lacks some important features, such as the automatic inclusion of referenced files (images, CSS, etc.).
The other viable method would be to use the Eclipse Mylyn Docs[2] tools. These only offers means to package already generated XHTML into an EPUB but does this in a fully featured[3] standards-compliant manner. It is also fairly easy to use.
[1] http://asciidoctor.org/docs/convert-asciidoc-to-epub/
[2] http://help.eclipse.org/neon/topic/org.eclipse.mylyn.docs.epub.help/help/epub-ant-task.html
[3] Only DRM and deprecated features have been omitted
### See also
* https://git.eclipse.org/r/111386
* https://git.eclipse.org/c/dash/org.eclipse.dash.handbook.git/commit/?id=1f495ca67ae33b0173e1204a29fd1eef4998c960https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/88Define "Project Code", "Third Party Content", and "Declared Licenses"2020-11-25T19:35:54ZEclipse WebmasterDefine "Project Code", "Third Party Content", and "Declared Licenses"## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526822)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526822)**
## Description
Add these terms to the glossary.
Should we also define "Project Content"?
I'm thinki...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526822)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526822)**
## Description
Add these terms to the glossary.
Should we also define "Project Content"?
I'm thinking that we define "Project Code|Content" as the content maintained by the project that contributes to the products ("content produced by project committers and contributors for adoption by the ecosystem and community"). i.e. distinguish it from "website content".
Third Party Content is content that is produced outside the Eclipse Foundation.
Declared Licenses is a synonym for Project Licenses, meaning the licenses by which content is received by the project team and then disseminated to consumers. Note that other Eclipse Project content, or third party content with compatible licenses may be distributed along with the project code; the Declared Licenses do not necessarily include these licenses.
Or something like that.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/87Move more of the content regarding Contribution Questionnaires to the Handbook2020-11-25T19:35:52ZEclipse WebmasterMove more of the content regarding Contribution Questionnaires to the Handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526744)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526744)**
## Description
There is some content here, including some board resolutions and a workflow diagram th...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#526744)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526744)**
## Description
There is some content here, including some board resolutions and a workflow diagram that may fit in the handbook.
Redirect wiki page to handbook when done.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/86Explicitely state that "Some Body" is a real name2020-11-25T19:35:50ZEclipse WebmasterExplicitely state that "Some Body" is a real name## Submitted by Oliver Kopp
**[Link to original bug (#526350)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526350)**
## Description
At the section "Git Commit Records" in the handbook (https://www.eclipse.org/projects/handbook/#re...## Submitted by Oliver Kopp
**[Link to original bug (#526350)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526350)**
## Description
At the section "Git Commit Records" in the handbook (https://www.eclipse.org/projects/handbook/#resources-commit) it reads
Signed-off-by: Some Body <somebody@somewhere.com>
It is not clear to readers that "Some Body" has to be a real name AND the name which was used for signing the ECA.
Most newcomers do not configure their git client correctly and I need a definitive source of truth (which is the handbook).
### See also
* https://git.eclipse.org/r/154335
* https://git.eclipse.org/r/154334
* https://git.eclipse.org/c/dash/org.eclipse.dash.handbook.git/commit/?id=87b769b99bc23136beec2198a6e045bf77f875c5https://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.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/84Replace EPL-1.0 by EPL-2.0 in "Example Copyright and License Header for Dual-...2021-06-01T15:36:35ZEclipse WebmasterReplace EPL-1.0 by EPL-2.0 in "Example Copyright and License Header for Dual-licensed Content"## Submitted by Oliver Kopp
**[Link to original bug (#526164)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526164)**
## Description
At https://www.eclipse.org/projects/handbook/#ip-copyright-headers, the "Example Copyright and Lic...## Submitted by Oliver Kopp
**[Link to original bug (#526164)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526164)**
## Description
At https://www.eclipse.org/projects/handbook/#ip-copyright-headers, the "Example Copyright and License Header for Dual-licensed Content" contains
SPDX-License-Identifier: EPL-1.0 OR Apache-2.0
but it should be
SPDX-License-Identifier: EPL-2.0 OR Apache-2.0
(note EPL-1.0 vs. EPL-2.0)
Because
* This program and the accompanying materials are made available under the
* terms of the Eclipse Public License 2.0 which is available at
* http://www.eclipse.org/legal/epl-2.0, or the Apache Software License
* 2.0 which is available at https://www.apache.org/licenses/LICENSE-2.0.
### Blocking
* [Bug 519789](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519789)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/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/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/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/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/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/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/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)