org.eclipse.dash.handbook issueshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues2021-03-24T20:56:28Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/38Provide some guidance on granularity of CQs2021-03-24T20:56:28ZEclipse WebmasterProvide some guidance on granularity of CQs## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#500460)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=500460)**
## Description
There is some confusion in the committer community regarding the expected granularity ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#500460)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=500460)**
## Description
There is some confusion in the committer community regarding the expected granularity for CQs. The IP Policy refers to "Content", but does not (AFAICT) suggest any particular level of granularity.
My understanding is that from the IP team's perspective, the desired granularity is the "library". That the library may manifest has multiple files is not relevant from an IP Due Diligence point of view.
For example, CQs 11879, 11880, 11881, 11882, 11883, 11884, 11885, 11886, 11887, 11888, 11889, 11890, 11891, and 11892 represent AngularJS 1.57 in (I believe) its entirely. All of these CQs point to the same "source URL". In fact, the committer created an "umbrella CQ" for these [1].
My understanding is that one CQ for AngularJS would suffice. That the library may be distributed as multiple individual .js files is irrelevant. Further, it would save both the committer and IP Team time (perhaps just a few minutes for each, but that adds up).
I've seen examples of this with Java libraries as well. One first possible example that I see is the combination of CQs 105 and 106 which represent the Xerces API and Implementation respectively. I believe that these two CQs represent just one library that happens to be distributed as two separate JAR files.
Another example is the difference in the way that Batik 1.6 and 1.7 are represented: there is a single CQ for version 1.6 and multiple CQs for each of the various parts that make up Batik 1.7.
Can we provide a simple definition of a library? e.g.
* All source comes from the same team/repository
* Provides some coherent bit of functionality
* May include separate but interdependent modules
* May manifest in deployment as multiple files
The actual definition is probably fuzzy, so the best that we can likely come up with is some guidance that saves everybody some time.
This probably belongs in the handbook. Maybe we can move it there once we have an answer.
[1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11804
### Blocking
* [Bug 496959](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496959)
* [Bug 508206](https://bugs.eclipse.org/bugs/show_bug.cgi?id=508206)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/54Add a "Getting Started" checklist2022-05-10T15:11:11ZEclipse WebmasterAdd a "Getting Started" checklist## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#510310)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=510310)**
## Description
We have a bit of a start on this in the "Starting an Open Source Project at Eclipse" s...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#510310)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=510310)**
## Description
We have a bit of a start on this in the "Starting an Open Source Project at Eclipse" section, but it's pretty high level and glosses over detail.
Further, having a more comprehensive check list gives us an opportunity to ensure that projects get off on the right foot.
Entries in the list should include:
* Ensure that all project committers have an Eclipse Foundation account;
After provisioning:
* Set up legal documentation (LICENSE.TXT) and about files;
* Add a CONTRIBUTING document;
* Upload your project logo
### Blocking
* [Bug 440244](https://bugs.eclipse.org/bugs/show_bug.cgi?id=440244)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/152Roll "The First 90 Days" into the Starting an Open Source Project section2022-05-10T15:11:11ZWayne BeatonRoll "The First 90 Days" into the Starting an Open Source Project sectionThere's some useful content on this page [The First 90 Days](https://wiki.eclipse.org/Development_Resources/The_First_90_Days). Let's roll it into the handbook and redirect this page to the handbook.There's some useful content on this page [The First 90 Days](https://wiki.eclipse.org/Development_Resources/The_First_90_Days). Let's roll it into the handbook and redirect this page to the handbook.