Eclipse Dash issueshttps://gitlab.eclipse.org/groups/eclipse/technology/dash/-/issues2024-03-26T18:33:31Zhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/184Add a pointer to our hugo-eclipsefdn-website-boilerplate project2024-03-26T18:33:31ZChristopher Guindonchris.guindon@eclipse-foundation.orgAdd a pointer to our hugo-eclipsefdn-website-boilerplate projectWe created a Hugo boilerplate project to help projects migrate their PHP website to Hugo.
I recently made some updates to our docs with pointers on how they can ask for help:
https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-eclips...We created a Hugo boilerplate project to help projects migrate their PHP website to Hugo.
I recently made some updates to our docs with pointers on how they can ask for help:
https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-eclipsefdn-website-boilerplate#how-to-build-my-projects-website-with-jenkins
This is an example of one of the many ways a project can create a website. Projects are not required to use this, however, this is the solution that we support.
I think it would be a good idea to include a pointer in the handbook to our boilerplate. I expect us to refine the docs overtime.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/183Add information about Matrix to the handbook2024-03-22T03:33:22ZWayne BeatonAdd information about Matrix to the handbookWhat do we need to tell commmitters about Matrix?What do we need to tell commmitters about Matrix?https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/182Domains that leverage EF trademarks must be owned by the EF2024-01-15T21:11:07ZWayne BeatonDomains that leverage EF trademarks must be owned by the EFNote that we consider all distinctive names of Eclipse projects -- whether they are formally registered or not -- to be trademarks of the Eclipse Foundation (referred to as "common law" trademarks in many jurisdictions).
The handbook cu...Note that we consider all distinctive names of Eclipse projects -- whether they are formally registered or not -- to be trademarks of the Eclipse Foundation (referred to as "common law" trademarks in many jurisdictions).
The handbook currently places very strong limitations on the use of domains.
It's commonplace for projects to have their own domains. What's actually important is that -- in order for the EF to be able to provide certain protections for the trademarks -- the EF needs to own and manage any domain that leverages our trademarks. So... this is the actual rule: domains that leverage Eclipse Foundation trademarks must be owned by the Eclipse Foundation.
If a project team takes it upon themselves to acquire a domain, they must transfer ownership of that domain to the Eclipse Foundation. The Eclipse Foundation does not generally acquire domains on behalf of projects, selecting a domain (and how to pay for the initial acquisition of that domain) are matters for the project team to sort out.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/113Make it clear that the project website must be hosted on EF managed servers2024-01-15T20:55:45ZEclipse WebmasterMake it clear that the project website must be hosted on EF managed servers## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#535141)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=535141)**
## Description
The section that discusses the project website implies, but does not state that the pr...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#535141)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=535141)**
## Description
The section that discusses the project website implies, but does not state that the project website must be hosted on EF managed servers.
That is, the website that the user ends up on by navigating to http://www.eclipse.org/`<short-name\>` must be running on EF infrastructure. This could be (as is default) the "PMI" page that's generated from project metadata, or a custom site that hosted on our www servers.
This URL must not, for example, redirect to a community portal.https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/120Add the Eclipse Foundations project server policy to the handbook2024-01-15T20:53:51ZEclipse WebmasterAdd the Eclipse Foundations project server policy to the handbook## Submitted by Eclipse Webmaster `@webmaster`
**[Link to original bug (#538607)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=538607)**
## Description
We've created the following policy for virtual machines provided by the Eclipse...## Submitted by Eclipse Webmaster `@webmaster`
**[Link to original bug (#538607)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=538607)**
## Description
We've created the following policy for virtual machines provided by the Eclipse Foundation.
`<----- Begin Policy ---->`
Project Server Policy
By operating a virtual server hosted either directly by the Eclipse Foundation or provided via the Eclipse Foundation’s funding in support of an Eclipse Foundation open source project to which you are a committer, you agree to the following:
1)To respond within 30 days to written requests eclipse.org-gdpr@eclipse.org to delete accounts or make user data available to the specific user in question. Server maintainers must subscribe to this list.
2)To collect only as much information is required to process the user’s request and to securely dispose of it when no longer required.
3)To make the contents of the server available for auditing should the need arise, and to provide support as required in order to carry out the audit process.
4)To take reasonable security precautions to prevent unauthorized access, and to notify the Eclipse Foundation (via privacy@eclipse.org) immediately if you suspect a security breach of any kind. Be sure to include the nature and scope of the suspected breach.
5)To ensure all web pages related to operation of the server use either the standard Eclipse.org footer template, or a footer that prominently contains a copyright notice, and the following set of links:
1) Main Eclipse Foundation website (http://www.eclipse.org)
2) Privacy policy (http://www.eclipse.org/legal/privacy.php)
3) Website terms of use (http://www.eclipse.org/legal/termsofuse.php)
4) Copyright agent (http://www.eclipse.org/legal/copyright.php)
5) Legal (http://www.eclipse.org/legal)
6)To ensure explicit consent has been given by the user before you can start using cookies. This requirement also includes cookies used by 3rd party services such as, but not limited to: Google Tag Manager, and social media widgets.
7)To ensure webpages related to the services being offered are fully compliant with the GDPR regulations
8)To not collect or track user activity on Eclipse Foundation-owned domains.
9)Google Analytics codes that do not belong the the Eclipse Foundation are prohibited
Failure to comply with this Policy may result in the server or funding in question being terminated without notice.
`<-------- End Policy ------>`
### Blocking
* [Bug 534384](https://bugs.eclipse.org/bugs/show_bug.cgi?id=534384)
### See also
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=552136https://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/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/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/181Enforcing 2FA on Gitlab Accounts2023-11-28T19:23:29ZTiago LucasEnforcing 2FA on Gitlab AccountsDear project committers, \
I would like to bring to your attention that the security team at the Eclipse Foundation will soon be requiring that accounts with committer privileges on gitlab.eclipse.org activate 2FA access control. \
The p...Dear project committers, \
I would like to bring to your attention that the security team at the Eclipse Foundation will soon be requiring that accounts with committer privileges on gitlab.eclipse.org activate 2FA access control. \
The plans, along with details on the importance of this change, have been [shared on the committers mailing list](https://www.eclipse.org/lists/eclipse.org-committers/msg01397.html). \
As included in the announcement, we are opening this ticket to inform you and track the activation of 2FA on accounts belonging to this projects’ members. \
To keep in mind, starting on on the **30th of October** you’ll likely see a banner each time you access GitLab reminding you to activate 2FA in your account. \
The deadline is **December the 4th**, by which access to your account will be limited until you activate 2FA. It is highly recommended that you enroll in this process before the deadline.
GitLab offers [instructions](https://gitlab.eclipse.org/help/user/profile/account/two_factor_authentication.md) on every step of the process and we’re happy to answer any question you might have. \
Thank you!
/cc @mbarbero
## FAQ
### How can I activate 2FA for my [gitlab.eclipse.org](https://gitlab.eclipse.org) account?
Detailed [instructions](https://gitlab.eclipse.org/help/user/profile/account/two_factor_authentication.md) are available. In a nutshell, visit [gitlab.eclipse.org/-/profile/two_factor_auth](https://gitlab.eclipse.org/-/profile/two_factor_auth) and follow the on-screen instructions.
If the form asks you for a password in order to set up 2FA on your account, this is not your Eclipse account’s password. It is a known bug on Gitlab that some accounts are requested a “local” password despite having one in the Active Directory. \
You should request a [password reset](https://gitlab.eclipse.org/-/profile/password/edit) and use that same password for this form. This process *does not* change your Eclipse account password.
### Do I need to purchase a hardware token for account access?
No. GitLab supports two 2FA methods:
_Time-based One Time Password_ (TOTP) compatible with mobile apps like Google Authenticator or Authy, and several password managers such as Bitwarden or 1Password.
_WebAuthN_, which necessitates a hardware token, typically a USB key (examples include [Solo 2 key](https://solokeys.com/) or [Yubikey](https://www.yubico.com/la-cle-yubikey/yubikey-5-series/)). These tokens are sometimes referred to as FIDO2 keys.
### How will this affect my [gitlab.eclipse.org](https://gitlab.eclipse.org) accounts?
In the near future, 2FA will become mandatory for authentication on your accounts. Should you not have enrolled by the deadline we communicated to you, access to the platform will be restricted.
### I already have 2FA enabled on [gitlab.eclipse.org](https://gitlab.eclipse.org), do I need to do anything?
No, you’re all good.
### What do I do if I lose my 2FA device?
We highly recommend the utilization of diverse secondary authentication methods. In the event that you misplace all your secondary authentication elements, recovery codes will be the only way to restore account access. By securely storing your recovery codes, you'll ensure the ability to regain access.
Note that the Eclipse IT team may be able to recover access to accounts with 2FA enabled if both the 2FA credentials and account recovery methods are lost. This will require extra identity verification and direct contact with [security@eclipse-foundation.org](mailto:security@eclipse-foundation.org) or [webmaster@eclipse-foundation.org](mailto:webmaster@eclipse-foundation.org).https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/179Add Committer Badge programme information to the handbook2023-11-21T17:07:00ZWayne BeatonAdd Committer Badge programme information to the handbookWe've captured the information in a [Google Doc](https://docs.google.com/document/d/1yZw9nCfvadWUrYo8kLDGxHXMW2mZPSrY6Fzjzw8drbU/edit?usp=sharing). Let's move that to the handbook.We've captured the information in a [Google Doc](https://docs.google.com/document/d/1yZw9nCfvadWUrYo8kLDGxHXMW2mZPSrY6Fzjzw8drbU/edit?usp=sharing). Let's move that to the handbook.2023-10-27https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/180Updates for Project Websites2023-10-19T09:02:02ZDenis RoyUpdates for Project WebsitesProject website URLs generally take the form `https://www.eclipse.org/<shortname>` (e.g. `https://www.eclipse.org/foo`
Please change to: Project website URLs generally take the form `https://eclipse.dev/<shortname>` (e.g. `https://eclip...Project website URLs generally take the form `https://www.eclipse.org/<shortname>` (e.g. `https://www.eclipse.org/foo`
Please change to: Project website URLs generally take the form `https://eclipse.dev/<shortname>` (e.g. `https://eclipse.dev/foo`https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/148Describe the GitHub Teams that we create in the handbook2023-09-18T19:33:37ZWayne BeatonDescribe the GitHub Teams that we create in the handbookFor those projects that host on GitHub, the EF maintains multiple teams:
* Project Leads get "Maintainer" access;
* Committers get "Write" Access; and
* Contributors get "Triage" access.
Project leads and committers are elected in the ...For those projects that host on GitHub, the EF maintains multiple teams:
* Project Leads get "Maintainer" access;
* Committers get "Write" Access; and
* Contributors get "Triage" access.
Project leads and committers are elected in the usual manner.
Contributors can be added to the project by editing the project metadata in the PMI and entering their email addresses in the "Source Code and Issues/Bugzilla" section.
Related:
* [Sync script issue](https://github.com/EclipseFdn/eclipsefdn-github-sync/issues/41)
@cguindon, can you confirm that what I've captured above is accurate? e.g., do project leads automatically get maintainer access, or do they need to request it?
Do you have any existing documentation that I can leverage here?Wayne BeatonWayne Beatonhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/149Include GitLab2023-09-18T19:33:28ZWayne BeatonInclude GitLabPretty much everywhere we reference GitHub, we should probably also reference GitLab.Pretty much everywhere we reference GitHub, we should probably also reference GitLab.Wayne BeatonWayne Beatonhttps://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/150Add a requirement/recommendation to provide a SECURITY file with project docu...2023-05-25T15:18:51ZWayne BeatonAdd a requirement/recommendation to provide a SECURITY file with project documentationConsider requiring/recommending that projects include a SECURITY file in their repositories.
The file should include a pointer to the [Eclipse Foundation Vulnerability Reporting Policy](https://www.eclipse.org/security/policy.php) along...Consider requiring/recommending that projects include a SECURITY file in their repositories.
The file should include a pointer to the [Eclipse Foundation Vulnerability Reporting Policy](https://www.eclipse.org/security/policy.php) along with implementation details that are specific to the project.
What implementation details should be included in the file?
* By what mechanism should vulnerabilities be reported
* How vulnerabilities are tracked by the project team
* By what criteria the project team will decide whether or not a CVE will be requested from the Eclipse Foundation
What else?Wayne BeatonWayne Beatonhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/170Graphical view of release workflow(s)2023-03-23T18:43:42ZWayne BeatonGraphical view of release workflow(s)_Moved from the EDP repository; this belongs in the handbook_
#### Issue/Problem Description
* It's a bit hard from the doc to understand which workflow a release can use and what are the steps involved in term of approval. Understandin..._Moved from the EDP repository; this belongs in the handbook_
#### Issue/Problem Description
* It's a bit hard from the doc to understand which workflow a release can use and what are the steps involved in term of approval. Understanding what a release involves requires moving in multiple places of the document and reading a lot of text, many of it being conditional, making it harder to sort out what's the path for a given case.
#### Proposal
* I suggest we show on the EDP a graphical view of the workflow(s) for releases. If there is actually no flow, but just a list of independent requirement, we should show the checklist for each review explicitly.
* The EDP release process could be an appendix, just like the IP Due Diligence poster which is extremely good for IP concerns (that I believe happen to be harder on paper, but easier to undersand thanks to the poster)
#### Proposal Benefits
* People understand release process better and can better pick the right kind of release they need according to their project constraints.
#### Challenges
* If it's an appendix, no immediate challenge.
* If we're likely to update the process often, then having an extra document could be an additional maintenance effort and a risk of out-of-date content.
/cc @mistriaWayne BeatonWayne Beatonhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/168Add information about resource packs to the handbook2023-02-03T11:41:15ZFrederic Gurrfrederic.gurr@eclipse-foundation.orgAdd information about resource packs to the handbookThis should include the content of the following sections:
* https://wiki.eclipse.org/CBI#What.27s_provided.3F
* https://wiki.eclipse.org/CBI#Additional_Resource_Packs
Content can also be used from
* https://wiki.eclipse.org/Jenkins#Abo...This should include the content of the following sections:
* https://wiki.eclipse.org/CBI#What.27s_provided.3F
* https://wiki.eclipse.org/CBI#Additional_Resource_Packs
Content can also be used from
* https://wiki.eclipse.org/Jenkins#About_resource_packs_and_quotas
More important than technical details (number of CPUs and RAM), is probably the process of how resource packs are assigned (https://wiki.eclipse.org/CBI#Assigning_Resource_Packs_to_a_Project) and how projects/orgs can check the status of resource pack allocation (https://wiki.eclipse.org/CBI#Sponsored_Projects).https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/161Handbook website is not in sync with the latest content from the GitLab repo2023-02-03T11:03:30ZFrederic Gurrfrederic.gurr@eclipse-foundation.orgHandbook website is not in sync with the latest content from the GitLab repoExample:
https://www.eclipse.org/projects/handbook/#resources-github-access
> Project leads are granted admin level access to their project’s GitHub repositories.
vs
https://gitlab.eclipse.org/eclipse/dash/org.eclipse.dash.handbook/-/...Example:
https://www.eclipse.org/projects/handbook/#resources-github-access
> Project leads are granted admin level access to their project’s GitHub repositories.
vs
https://gitlab.eclipse.org/eclipse/dash/org.eclipse.dash.handbook/-/blob/master/source/chapters/resources.adoc#resources-github-access
> Project leads are granted `maintain` level access to their project’s GitHub repositories. \
> A project lead may request temporary `admin` level access to their project’s repositories by {helpdeskUrl}\[creating a Help Desk issue\]. The issue must describe what will be done using this new level of access and how long it will be needed.|
>
This caused confusion here: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1221#note_711665
Please update the handbook website with the latest content from the GitLab repo to avoid further confusion.Wayne BeatonWayne Beatonhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/166Revise the Initial Contribution Process2022-12-19T03:57:39ZWayne BeatonRevise the Initial Contribution ProcessIn the past, we required that project teams provide a ZIP file containing a snapshot of their repository to the IP Team for review via IPZilla. The team was then "on hold" until the IP Team granted their approval to "check-in"; with that...In the past, we required that project teams provide a ZIP file containing a snapshot of their repository to the IP Team for review via IPZilla. The team was then "on hold" until the IP Team granted their approval to "check-in"; with that approval, the project team could then work with the IT team to move/create repositories.
With the changes in the IP Policy, we have an opportunity to improve this experience.
The short version is this:
* Complete the proposal process and creation review;
* Project team and EMO works with IT Team to move existing repositories (or create new ones) in EF GitLab or EF-managed GitHub;
* EMO will initiate the intellectual property review of the default branch of all repositories;
* The EMO IP Team will inform the EMO when the reviews are complete.
Note that the overall process likely takes the same amount of time with these revisions as it did in the past. The perception and general experience should, however, be better for the committer teams involved.
We need to take special care to ensure that project teams understand that when we move repositories under management of the EFs, the repositories will become immediately subject to our system's management of project roles. Write access to repositories will, for example, be limited to committers who are listed on the project proposal and have signed the necessary agreements.
That is, some committers may lose access during the transition period, so care should be taken with regard to timing of the move. It is a best practice, therefore, to wait until a critical mass of committers have been onboarded before starting to move any repositories.
Note that the process is basically the same when a repository of existing code is added to a running project. We can likely do something similar with pull requests that require review (more investigation required).
/cc @mdelgado624 @skilpatrick2022-12-16https://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?