Eclipse Dash issueshttps://gitlab.eclipse.org/groups/eclipse/technology/dash/-/issues2020-11-25T19:32:07Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/1Project Criteria for becoming a Committer.2020-11-25T19:32:07ZEclipse WebmasterProject Criteria for becoming a Committer.## Submitted by David Carver
**[Link to original bug (#283880)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=283880)**
## Description
I have done a little research and currently there seems to be no documentation for any particular...## Submitted by David Carver
**[Link to original bug (#283880)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=283880)**
## Description
I have done a little research and currently there seems to be no documentation for any particular project on how somebody gets invited to be a committer. Are the rules different if they are a member company versus a contributer from the outside. What are the projects specific requirements.
Many times projects are saying they don't have time to do the work, because of lack of resources, but are they providing the necessary documentation on the criteria they expect for a somebody that wants to become a committer. Are they actively seeking and trying to recruite new committers.
It would help both existing projects, and new projects at eclipse if we could come up with some guidelines on how to document these requirements. I realize they will vary by project but having something for your user community can be a great help.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/2IP Log Contribution Doc is wrong (not updated for Git)2020-11-25T19:37:28ZEclipse WebmasterIP Log Contribution Doc is wrong (not updated for Git)## Submitted by Dani Megert
**[Link to original bug (#387767)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=387767)**
## Description
http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log#Contributors
does not say anything...## Submitted by Dani Megert
**[Link to original bug (#387767)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=387767)**
## Description
http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log#Contributors
does not say anything about Git (setting author).
### Blocking
* [Bug 435933](https://bugs.eclipse.org/bugs/show_bug.cgi?id=435933)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/3All Eclipse project Git repositories must include a contribution guide2021-09-24T20:26:45ZEclipse WebmasterAll Eclipse project Git repositories must include a contribution guide## Submitted by Krum Tsvetkov
**[Link to original bug (#397644)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=397644)**
## Description
Created attachment 225328
draft proposal for the recommendation
There was a proposal on the cro...## Submitted by Krum Tsvetkov
**[Link to original bug (#397644)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=397644)**
## Description
Created attachment 225328
draft proposal for the recommendation
There was a proposal on the cross-project-issues list that projects should provide an explicit target definition:
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08372.html
The proposal was discussed on the AC meeting on 13 Dec 2012:
http://wiki.eclipse.org/Architecture_Council/Meetings/December_13_2012#New_Topics
As not all projects are using Tycho as a build technology, the outcome of the discussion was to provide a more general recommendation that projects should provide a "how to contribute" page, and describe that using an explicit target definition is one good option for handling the dependencies.
We also discussed that it could be useful to give some concrete examples of contribution guides.
I tried to write up a draft for such a recommendation.
However, I'm not sure where to put it in Wiki, so for now I attach it as plain text here.
What could be a proper place in the Wiki for such a recommendation? I will format it then and put it there, instead of using a txt file :)
What do you think about the attached description?
I think it would be nice to have also other technical options described, but my own experience so far is with using Tycho and I couldn't write it.
What about the examples? I just picked a few, but haven't really looked into all projects.
~~**Attachment 225328**~~, "draft proposal for the recommendation":
[Recommendation_Target_Platform.txt](/uploads/09db0c90c6ad2aea2a1778cc0e55ed09/Recommendation_Target_Platform.txt)
### Blocking
* [Bug 404585](https://bugs.eclipse.org/bugs/show_bug.cgi?id=404585)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/167[Bug 415631] [EDP] EMO vs. EMO(ED)2022-11-08T16:01:55ZWayne Beaton[Bug 415631] [EDP] EMO vs. EMO(ED)| | |
| --- | --- |
| Bugzilla Link | [415631](https://bugs.eclipse.org/bugs/show_bug.cgi?id=415631) |
| Status | NEW |
| Importance | P3 normal |
| Reported | Aug 21, 2013 16:31 EDT |
| Modified | Oct 11, 2020 16:14 EDT |
## Descript...| | |
| --- | --- |
| Bugzilla Link | [415631](https://bugs.eclipse.org/bugs/show_bug.cgi?id=415631) |
| Status | NEW |
| Importance | P3 normal |
| Reported | Aug 21, 2013 16:31 EDT |
| Modified | Oct 11, 2020 16:14 EDT |
## Description
I believe that in some cases, the EDP uses the terms "EMO" and "EMO(ED)" inconsistently.
From section 4:
--\
As defined by the Eclipse Bylaws - Article VII, the Eclipse Management Organization (EMO) consists of the Foundation staff and the Councils. The term EMO(ED), when discussing an approval process, refers to the subset of the EMO consisting of the Executive Director and whomever he or she may delegate that specific approval authority to.\
--
We then have statements like this in section 4.5:
--\
The Scope of a Sub-Project is defined by the initial project proposal as reviewed and approved by the Project Management Committee (PMC) (as further defined below) of the Project's Project's top parent and by the EMO. \
--
In practice "EMO" means "Wayne and Mike". In this particular case, I'm all for course-correcting my process to more explicitly put project proposals in front of the councils and seek their approval. Is this desired, or does it add too much process? (making sure that the councils are aware of new projects seems like a good idea to me).
In section 6.2.1, "EMO" really means "Wayne": "The EMO will assist such groups in the preparation of a project Proposal." and "The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO".
Section 6.3 mixes the roles up nicely...
"the EMO may initiate a Review on the Project's behalf" is--I think--wrong. I believe that it should be the PMC (see [Bug 344041 Comment 6](https://bugs.eclipse.org/bugs/show_bug.cgi?id=344041#c6)).
Also in that section: "A Review then continues with the Project's Leadership requesting that the EMO(ED) schedule the Review.", "Prior to the start of the review period, the Project leadership provides the EMO with review documentation.", and 'The EMO announces the Review schedule and makes the documentation available to the membership-at-large."
Further: "The Review begins with the EMO's posting of the review materials at the start of the Review period", and "The EMO(ED) approves or fails the Review based on the public comments, the scope of the Project, and the Purposes of the Eclipse Foundation as defined in the Bylaws." mix up the two terms.
In all these cases, "EMO" and "EMO(ED)" means "Wayne" (I am the EMO(ED) delegate in this case).
There are more examples.
Do we need to define a new role (e.g. Director of Open Source Projects)?
Or is it just the case that "Wayne" is the practical representative of the EMO and engages in all of these activities on behalf of the larger body, and we should change appropriate occurrences of "EMO(ED)" to "EMO"?
Or should we just update appropriate occurrences of "EMO" to "EMO(ED)" and Mike and I can hash out which parts he'll delegate to me?https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/4Landing page/description/getting starting page for IPZilla2020-11-25T19:32:31ZEclipse WebmasterLanding page/description/getting starting page for IPZilla## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#439531)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=439531)**
## Description
I can't find a landing page that concisely describes IPZilla. Do we have one?
This on...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#439531)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=439531)**
## Description
I can't find a landing page that concisely describes IPZilla. Do we have one?
This one looks promising, but is more of a proposal to build rather than a description.
https://wiki.eclipse.org/IPzilla
Perhaps we can re-purpose that page...
### 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/5Provide better help regarding the content of the committer election merit sta...2020-11-25T19:32:34ZEclipse WebmasterProvide better help regarding the content of the committer election merit statement## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#460734)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=460734)**
## Description
Committer elections require a statement of merit. We should provide more help for nomi...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#460734)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=460734)**
## Description
Committer elections require a statement of merit. We should provide more help for nominators to make sure that they get it right the first time.
Ideally, a nomination's statement of merit will list a handful of contributions (with links) made by the nominee. Rationalization that an individual has made significant contributions to the initial contribution in the past is also sufficient. e.g. "Bob has made significant contributions to the project; he created the such-and-such subsystem. He is joining the project to maintain and grow that functionality." (or something like that).
There is some discussion on [Bug 283880](https://bugs.eclipse.org/bugs/show_bug.cgi?id=283880). Also see [Bug 366435](https://bugs.eclipse.org/bugs/show_bug.cgi?id=366435) regarding automatic generation of merit statements.
### Depends on
* [Bug 440818](https://bugs.eclipse.org/bugs/show_bug.cgi?id=440818)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/6Move Project Handbook source to Dash2020-11-25T19:32:38ZEclipse WebmasterMove Project Handbook source to Dash## Submitted by Wayne Beaton `@wbeaton`
Assigned to **Wayne Beaton `@wbeaton`**
**[Link to original bug (#475496)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=475496)**
## Description
I created the handbook source in the /projec...## Submitted by Wayne Beaton `@wbeaton`
Assigned to **Wayne Beaton `@wbeaton`**
**[Link to original bug (#475496)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=475496)**
## Description
I created the handbook source in the /projects directory directly. I did this primarily out of convenience so that I could focus on content. Now that I've completed the first version of the handbook, I'd like to extract the source from /projects and put it into its own dedicated repository. I'd like that repository to be connected into Gerrit.
I believe that moving it to Dash makes sense. I believe that the handbook reasonably qualifies as a tool for committers, so it is in-scope. The handbook source can be moved into its own repository and easily connected to Gerrit. Further, by having it in a project, we can request a Hudson instance to provide some CI functionality.
In these early days, it's been convenient to be able to push out regular minor updates, but now that we've reached a level of maturity, it makes sense to start treating the handbook like an actual project and schedule actual releases. i.e. conform to the development process.
Actual release content will be pushed into the /project directory (where it currently resides).
### Blocking
* [Bug 482414](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482414)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/7Enrich Eclipse Project Handbook with links to further readings2020-11-25T19:32:43ZEclipse WebmasterEnrich Eclipse Project Handbook with links to further readings## Submitted by Eike Stepper
**[Link to original bug (#477761)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=477761)**
## Description
In the Eclipse Project Handbook there is a section on the initial contribution, but that is not v...## Submitted by Eike Stepper
**[Link to original bug (#477761)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=477761)**
## Description
In the Eclipse Project Handbook there is a section on the initial contribution, but that is not very detailed. The details are indeed on their own page. I propose to add a link to it:
https://wiki.eclipse.org/Development_Resources/Initial_Contribution
The same applies to the section on Copyright and License header. There could be links to the Eclipse Copyright Tool:
https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool
and secondly to the Legal Documentation Guide:
https://www.eclipse.org/legal/guidetolegaldoc2.phphttps://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/9Create a Maven build for the Eclipse Project Handbook2020-11-25T19:32:46ZEclipse WebmasterCreate a Maven build for the Eclipse Project Handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#482415)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482415)**
## Description
The current make-based build is clunky and brittle (mostly due to my inexperience with...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#482415)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482415)**
## Description
The current make-based build is clunky and brittle (mostly due to my inexperience with the tool, I'm sure). Maven builds are cool, sleek, and clean. We need a Maven build.
The handbook content is divided up into several files that are combined via specific documents for each of the (current) three forges: eclipse.adoc, location.adoc, and polarsys.adoc files. The config.adoc file contains the common configuration for each of the document variants.
Note that the Handbook includes some DOT files that use Graphviz for rendering.
While low priority, it'd be cool if we can generate good PDFs. The fop-based generation that we're currently using has trouble generating images of reasonable size (they all render far too large).
The directory structure can be modified if necessary.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/10Oomph setup for dash.handbook2020-11-25T19:32:48ZEclipse WebmasterOomph setup for dash.handbook## Submitted by Jeremie Bresson
**[Link to original bug (#482962)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482962)**
## Description
In my opinion each project at Eclipse should have an Oomph setup task, even for simple task.
...## Submitted by Jeremie Bresson
**[Link to original bug (#482962)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=482962)**
## Description
In my opinion each project at Eclipse should have an Oomph setup task, even for simple task.
In case of the Dash Handbook project, we need to:
* checkout the repo
* import the project: "Eclipse Project Handbook"
I also think that it would be nice to leverage other existing editors, even if they are not perfect (yet):
* AsciiDoc format support using Mylyn Docs [1] (Mylyn Docs Extras from the "Mylyn WikiText nightly" update site).
* Dot Graph format (from the GEF4 project) [2]: the editor is nice (syntax highlighting, error detection, CTRL+Space...), the preview view is limited (Graph capabilities from the Zest Framework), the outline view can be useful.
In addition:
1/ I think that it is OK to add the "org.eclipse.xtext.ui.shared.xtextNature" to the Eclipse Project Handbook. It is requested by the Dot SDK, but it will not affect users that do not use it.
2/ The "Sync with printable PDF using Graphwiz" feature in the Dot SDK produces PDF files in "/Eclipse Project Handbook/source/images/". I think an entry in gitignore is useful to prevent those files to be submitted.
I will submit a patch.
[1] https://wiki.eclipse.org/Mylyn/WikiText/AsciiDoc
[2] https://wiki.eclipse.org/GEF/GEF4/DOT
### See also
* https://git.eclipse.org/r/61211
* https://git.eclipse.org/c/dash/org.eclipse.dash.handbook.git/commit/?id=c70bbdebecabcaaa9bb4e581c3e247d1964665b3https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/11Add information about incubation mailing list to handbook2020-11-25T19:32:50ZEclipse WebmasterAdd information about incubation mailing list to handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#483809)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=483809)**
## Description
Let's point new committers to the incubation@eclipse.org mailing list.
https://dev.ec...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#483809)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=483809)**
## Description
Let's point new committers to the incubation@eclipse.org mailing list.
https://dev.eclipse.org/mailman/listinfo/incubation
I think that this fits well into the "Starting an Open Source Project" section.
Where else? I think that we need a "so you're a new committer" section.
### Depends on
* [Bug 463849](https://bugs.eclipse.org/bugs/show_bug.cgi?id=463849)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/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/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/15Add release review checklist to the handbook2020-11-25T19:33:01ZEclipse WebmasterAdd release review checklist to the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485704)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485704)**
## Description
Add some variation of the release review checklist in the wiki to the handbook.
Consi...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485704)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485704)**
## Description
Add some variation of the release review checklist in the wiki to the handbook.
Consider creating the checklist as a separate source file so that it can more easily be reused in other contexts.
### Depends on
* [Bug 505741](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505741)
* [Bug 509389](https://bugs.eclipse.org/bugs/show_bug.cgi?id=509389)
### Blocking
* [Bug 511789](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511789)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/16Document how projects can use GitHub, including issues, wiki, and releases2020-11-25T19:33:03ZEclipse WebmasterDocument how projects can use GitHub, including issues, wiki, and releases## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485964)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485964)**
## Description
We need to document how projects are expected to use GitHub. We have board approval fo...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485964)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485964)**
## Description
We need to document how projects are expected to use GitHub. We have board approval for projects to use GitHub repositories and Issues with an understanding that the webmaster team is able to provide complete backups of the captured information thereby providing the necessary freedom of action.
Use of repositories is approved by the board of directors. This extends to the use of wiki which is effectively a Git repository that contains documentation.
The use of GitHub Issues is approved by the board of directors. The resolution indicates that PMC approval is required.
GitHub Releases can be used, but the PMI must be used as the canonical location for review documentation. Similarly, the EF-provided download server is the canonical location for distribution of project artifacts.
The handbook is probably the right home for this documentation, but I thought that I'd start the bug here to make sure that we've correctly captured the requirements.
### Depends on
* [Bug 506836](https://bugs.eclipse.org/bugs/show_bug.cgi?id=506836)
* [Bug 517749](https://bugs.eclipse.org/bugs/show_bug.cgi?id=517749)
* [Bug 520706](https://bugs.eclipse.org/bugs/show_bug.cgi?id=520706)
### Blocking
* [Bug 481771](https://bugs.eclipse.org/bugs/show_bug.cgi?id=481771)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/17Provide guidance regarding project logos in the handbook2020-11-25T19:33:07ZEclipse WebmasterProvide guidance regarding project logos in the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485966)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485966)**
## Description
The short version:
The project logo is intellectual property, so be sure that you're ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#485966)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=485966)**
## Description
The short version:
The project logo is intellectual property, so be sure that you're not infringing on anybody's trademark or copyright.
Logos are not typically shipped as project code, so you don't generally need to get IP Team approval.
If the logo incorporates the Eclipse Logo, you'll need to get board approval.
### Depends on
* [Bug 498236](https://bugs.eclipse.org/bugs/show_bug.cgi?id=498236)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/18Update discussion regarding GitHub2020-11-25T19:33:09ZEclipse WebmasterUpdate discussion regarding GitHub## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487243)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487243)**
## Description
The handbook currently says "Projects that host source code on GitHub are not permitte...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487243)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487243)**
## Description
The handbook currently says "Projects that host source code on GitHub are not permitted to use GitHub Issues or Wiki."
This is no longer true.
### Blocking
* [Bug 481771](https://bugs.eclipse.org/bugs/show_bug.cgi?id=481771)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/19Move more of the Initial Contribution content into the handbook2020-11-25T19:33:11ZEclipse WebmasterMove more of the Initial Contribution content into the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487246)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487246)**
## Description
The wiki provides a little more detail on initial contributions that would be a valuab...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#487246)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=487246)**
## Description
The wiki provides a little more detail on initial contributions that would be a valuable addition to the handbook.
https://wiki.eclipse.org/Development_Resources/Initial_Contribution
Move this content and update the wiki.
### Depends on
* [Bug 494955](https://bugs.eclipse.org/bugs/show_bug.cgi?id=494955)
* [Bug 488237](https://bugs.eclipse.org/bugs/show_bug.cgi?id=488237)