I’ll admit that a really big part of me wanted to see who would notice.
Last week, I relatively quietly changed how we represent project metadata by switching parts of the Eclipse projects website and the corresponding elements in the developer portal over to the new Project Management Infrastructure (PMI). If you click on the “About this Project” link for any project, or click the “All Projects” link on the Eclipse Projects page, you’ll be taken over to the new stuff.
Projects are the central feature of the PMI. Here’s an example:
You’ll notice some structural similarities to the old “Project Info|Summary” pages.
The main content of the page shows various bits of information, including the licenses used by the project, releases, reviews, and various graphs. I’m particularly fond of the “Contribute to this project” section which provides a bunch of handy information for prospective contributors, including links to the project’s repositories, and Bugzilla coordinates. I’m planning to add in links to information regarding builds and such as well.
The left navigation area shows an overview of the project. In this case, the shows the list of simultaneous releases the project has participated in, along with some handy links to information. Among the links is one that will display a page of project developers, one that will display the full set of releases, and some convenience links to display the current and next releases. Each release gets its own page (but I’ll take more about that in a follow up post).
A couple of committers noticed this week that the “Manage project metadata” link disappeared from the developer portal. The edit functionality for the data projects collect has been moved into the PMI.
Any registered user can log into the PMI. If you’re a committer or project lead the a project, an “Edit” button (link) will appear. If you click that, an editor will open and you can change information about the project.
You may notice that we provide fields to collect a few more bits of data than we currently display. We don’t, for example, actually use the “Build URL” field yet; but that’s coming soon. You’ll also notice that some of the fields provide autocompletion help (the mailing list fields in particular).
Note that you can use wildcards when specifying source repositories. For example, specifying ‘/gitroot/cdt/*’ will result in all Git repositories found nested under /gitroot/cdt/ will appear in the “Contributing to this project:” section.
A project lead or committer can now directly update the description of the project. The description was taken from the value previously provided via a file containing some HTML in your project’s web directory; projects no longer need that file. You may also notice that a project’s scope is now explicit. The scope was taken from corresponding section in each project’s proposal (when linkage to the proposal could be determined). Both of these values can be edited. Take care when editing the scope that you don’t change the meaning. Changing the text is fine; changing the meaning of the scope requires community review.
The migration over to this new infrastructure will occur in stages. In this first stage, we’ve migrated projects, releases, reviews, and simultaneous releases. For committer management (electing and retiring committers) and creating CQs, you’ll need to keep using the developer portal.
I expect that a few things (including documentation) will break during the migration, but we’ll fix those breaks as they occur. When you notice that something isn’t working quite right, or it’s not clear how it’s supposed to work, let me know. Opening a bug against Community/Project Management & Portal is the preferred means of communicating the problem. If that doesn’t work for you, send a note to emo@eclipse.org.
