Wayne Beaton (50b02e4a) at 27 Mar 21:40
Add an FAQ entry discussing why there is no project manager role
Wayne Beaton (782bf6f1) at 27 Mar 21:37
Add some guidelines for committer election criteria
Wayne Beaton (94afc297) at 27 Mar 00:08
Remove the Generative Artificial Intelligence Usage Guidelines
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.
What do we need to tell commmitters about Matrix?
Wayne Beaton (a4da5544) at 22 Mar 03:11
Add the Generative Artificial Intelligence Usage Guidelines
Wayne Beaton (1ac65b1e) at 25 Feb 04:10
Don't add copyright information in the callouts.
Wayne Beaton (1956e099) at 15 Feb 19:05
Use dep5 for all metadata for callout PNGs
Wayne Beaton (764e8e03) at 15 Feb 04:30
Clean up licenses; restore REUSE compliance.
Wayne Beaton (ded1526b) at 15 Feb 04:29
Remove Eclipse metadata
Those are separate ideas so would be good to put them in separate paragraphs. For example (with editing), see below. I've updated the vocabulary to be in sync with the rest of the document. If you mean a release review process as 'review process', the new process is different and projects go by the review once per year only. There is no impact on bugfix releases. @wbeaton could you confirm.
And here's my proposal of the rewrite.
It should be noted that vulnerabilities have different severities and not all of them need the same reaction. Some (low severity) vulnerabilities might not need a fix at all if documented or if a viable workaround exists.
In case of a critical vulnerability, the project might decide to perform an emergency bugfix release.
It is a common practice to resolve vulnerabilities by upgrading the dependencies for your next project release.
This sentence is quite long. I would recommend to spit it in a number of sentences to keep a clear flow.
First part: this is up to the project to decide if they fix or not, but the researcher might disagree with them. Not fixing might have high impact on the reputation of the project, as at the end all vulnerabilities to Eclipse projects are disclosed. This is not possible for a project to keep an unfixed vulnerability not known to the public. The researcher might disclose the vulnerability on their side, they can also apply for a CVE on their own.
There are also expressions I do not understand: what does it mean "mandated by the Foundation" here?
Second part: you probably mean "vulnerability detected IN the third party dependencies"
There are way more: vulnerabilities in the hardware the software or build is running on, vulnerabilities in 3rd party services (which are not dependencies) and so on. I also do not understand what this introduction is leading to. This classification does not seem to be used below.
Wayne Beaton (bd1d258a) at 31 Jan 18:50
Include a change log
Wayne Beaton (49255af2) at 31 Jan 04:23
Be consistent that the copyright year is the year of initial creation
Wayne Beaton (e2c8bcd8) at 15 Jan 21:11
Domains that leverage EF trademarks must be owned by the EF #182
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.
@webmaster if I remember correctly, we no longer provide virtual servers for Eclipse projects. Is this accurate?
Assuming that my member serves me well... I believe that this is more of a working group concern at this point. Does that make sense to you?
@wbeaton
Link to original bug (#527361)
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.