org.eclipse.dash.handbook issueshttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/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/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/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/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/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?https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/30Include discussion of the Security Policy in the handbook2022-10-17T19:16:05ZEclipse WebmasterInclude discussion of the Security Policy in the handbook## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#496426)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496426)**
## Description
We may only need a pointer. But we should have that pointer.
### Depends on
* [Bug ...## Submitted by Wayne Beaton `@wbeaton`
**[Link to original bug (#496426)](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496426)**
## Description
We may only need a pointer. But we should have that pointer.
### Depends on
* [Bug 496425](https://bugs.eclipse.org/bugs/show_bug.cgi?id=496425)
* [Bug 514571](https://bugs.eclipse.org/bugs/show_bug.cgi?id=514571)
### Blocking
* [Bug 510142](https://bugs.eclipse.org/bugs/show_bug.cgi?id=510142)
* [Bug 511789](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511789)https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/164Update contact information to point people to create "help desk" issues2022-06-13T18:14:58ZWayne BeatonUpdate contact information to point people to create "help desk" issuesSome of the handbook has been updated to refer to help desk, but not all.
We should review references to the webmaster email address and determine whether or not a pointer to help desk is a better fit.Some of the handbook has been updated to refer to help desk, but not all.
We should review references to the webmaster email address and determine whether or not a pointer to help desk is a better fit.Wayne BeatonWayne Beatonhttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/163Ability to display a summary of clearlydefined findings2022-05-18T06:34:18ZBoris BaldassariAbility to display a summary of clearlydefined findingsAs discussed during our last call, it would be great to have an option for dash that displays a summary of all findings retrieved from clearlydefined. The idea is to use this summary to build ORT's curations file afterwards.
If we get t...As discussed during our last call, it would be great to have an option for dash that displays a summary of all findings retrieved from clearlydefined. The idea is to use this summary to build ORT's curations file afterwards.
If we get the "canonical path" (e.g. `npm/npmjs/@fluentui/react-text/9.0.0-alpha.13`) or whatever similar format that can be easily transformed that'd be enough for our purpose.https://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.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/162Update the "Starting an Open Source Project at the Eclipse Foundation"2022-05-10T15:11:10ZWayne BeatonUpdate the "Starting an Open Source Project at the Eclipse Foundation"This section needs some work.
Here are some resources that might help:
* Add a Getting Started Checklist #54
* "The First 90 Days" #152
* Trademarks #118
* [Starting a Project at the Eclipse Foundation](https://www.eclipse.org/commun...This section needs some work.
Here are some resources that might help:
* Add a Getting Started Checklist #54
* "The First 90 Days" #152
* Trademarks #118
* [Starting a Project at the Eclipse Foundation](https://www.eclipse.org/community/eclipse_newsletter/2014/july/article2.php)Maria Teresa DelgadoMaria Teresa Delgadohttps://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/159Inform new committers of the mailing lists to which they will automatically b...2022-02-14T21:15:35ZWayne BeatonInform new committers of the mailing lists to which they will automatically be subscribedWe have some scripts that automagically subscribe committers to various mailing lists.
@webmaster, can you please confirm that these are the lists (are there any more?):
* eclipse.org-members-committers@eclipse.org
* eclipse.org-commit...We have some scripts that automagically subscribe committers to various mailing lists.
@webmaster, can you please confirm that these are the lists (are there any more?):
* eclipse.org-members-committers@eclipse.org
* eclipse.org-committers@eclipse.org
We need to ensure that new committers are aware that they they will automatically be subscribed and must remain subscribed as part of the process of becoming a committer.
Do we automatically subscribe committers to their project's dev list? (per comments on Bug 437377, I think that this is a bootstrapping problem).
We should include pointers to other lists that may be useful (e.g. project dev list, cbi-dev, cross-project-issues-dev).