Project Management Infrastructure/Project Metadata
What is Project Metadata?
- Relatively static structural information such as the project description and scope, the names of the project's mailing lists and newsgroups, the bugzilla products, source code repositories, etc.
- Historical information such as previous release downloads, release review slides and IP logs, etc.
- Status and future looking information such as the project and milestone plans, the features scheduled for the current release, release dates, etc.
Who maintains it?
Eclipse committers and project leads are responsible for maintaining their project's metadata. This information is an important part of being an Eclipse project.
PMC members, and the Eclipse Foundation staff also have the ability to make changes on behalf of a project.
The complete listing of all current Eclipse projects provides one starting point for viewing projects. From here, you can link directly to a project information page. Navigation options are provided to help you move from one project to another.
Here is an example of a project page (visit the live project page).
Editing Project Metadata
If you are a project committer, you can authenticate with the system by clicking the "Login" link. Once logged in, you will have the ability to edit the information being displayed.
There are several sections on the page. When you switch the page into "Edit" mode, you will be provided with lots of help regarding the contents of each of the fields (note that the help text is currently rendered below the fields).
Commands and Tools
If you are logged in, you will have access to several committer-specific commands and tools. These are available in the "tray" area on the page.
The selection of commands available are context sensitive; only those commands that make sense for the logged in user are shown.
The tray can be expanded or collapsed by clicking on the title in the tray area.
Description and Scope
At the top are the description and the scope. The description should be suitable for display with a collection of other projects (e.g. Use of Maven Build Technology). A single paragraph is generally appropriate for the description.
If you feel that more than a single simple paragraph is required, you can provide a single paragraph summary. Note that providing a summary gives you control over what will get rendered. In views where we are displaying more than one project (e.g. Maven), the system will artifically cut short descriptions that are too long, potentially resulting in a description that looks weird.
The scope is intended for a more select audience; generally speaking the scope should be taken directly from the project's proposal. Project members have the ability to change the text of the project scope, but should be careful to avoid changing the meaning. If the meaning of the scope needs to change, consult your PMC regarding a restructuring review.
You can provide download information for your project in the "Downloads" section.
The first entry is the main "Downloads URL". This manifests as a "Big Button" Download on the project page. What you put here is up to you. It can be a link to a webpage, a direct link to a file download, or whatever else makes sense to you and your project's community.
You can optionally provide some text to include along with the "Big Button" Download, as well as links to zero or more Eclipse Marketplace, update/p2 sites, or other downloads. Each of the links can have an optional title (the link itself will be displayed if no title is provided). Note that no validation is done on the links to ensure that they are meaningful. It is up to use to employ the principle of least surprise for your community and adopters.
Here is an example of a project that has specified a download URL ("Big Button" download) and a single Marketplace Entry:
Here's another example:
The Eclipse Foundation strongly encourages all projects to create an maintain and Eclipse Marketplace presence.
Project Plan, and Release Links
The navigation area contains a link to the project plan. The value that is displayed here depends on the information provided. If you provide a link in the project's "Project Plan" field, that value will be used as the link. Otherwise, the PMI will create a link to a plan automatically generated from plan information provided in the chronologically next release. Note that the use of the "Project Plan" field is discouraged in favour of the plan generated from release data.
Eclipse projects can specify an XML URL in the standard format; in this case, the link will be modified to point to the project plan rendering script.
The links to the current and next release are automatically generated based on the dates of the project releases.
Each release has its own record in the database. Records are connected directly to a single specific project; a subset of release records associated with a project are displayed on the project page. An existing release can be edited in much the same was as a project. Any logged in project member (committer or project lead) can click the "Edit" button.
For information regarding releases, including how to create new release records, please see Release Metadata.
The project can specify zero or more source repositories. These are displayed in the "Contribute to this Project" section.
The values specified are used to query against a database of known existing source repositories (this database is updated nightly by a discovery process). Those repositories that are found in the database will be displayed with enhanced information (including links to repository mirrors, Gerrit, etc.). All values that you provide will be displayed, whether they point to real repositories or not. If the database does not contain your repository, the PMI will assume that you know what you're doing and try its best to display the information. Note that it is assumed that any repository you list exists on the forge.
Repositories should be specified using the file system path, e.g. '/gitroot/egit/egit.git'. The name that is displayed for the repository is extracted from the last segment of the URL.
If a description file exists in the Git repository, the contents are displayed under the repository name.
The script that we us to identify repositories attempts to identify a corresponding Gerrit interface for the repository. If it exists, the Gerrit URL is used in place of the Git one. If the repository uses Gerrit, then only the Gerrit URL is displayed. Otherwise, the "git://" and "ssh://" URLs are displayed.
The script also searches for GitHub and Google Source mirrors. If they exist, they are displayed in this section. The "clipboard" icon will, when clicked, copy the URL to the clipboard.
You can use wildcards to match multiple repositories, e.g. '/gitroot/virgo/*'. Note that wildcards only work for repositories that are represented in our database. If you use a wildcard entry, matching entries may not appear until the discovery process runs.
Repositories are displayed in the order they are specified. The order can be changed in the edit screen by dragging entries into the desired order. All wildcard matches are sorted alphabetically by name at the end of the list.
You can optionally provide a Contribution Message that is displayed at the top of the section. Arbitrary text is permitted, but we recommend that you limit this content to a single paragraph with a few sentences that include a link to more information. For more information regarding what you should include here (or in a more comprehensive contribution guide), please see bug 397644.
Company logos sometimes appear under the project members on the right. Here's what you need in order to get your company's logo to show up in this pane:
- The company must be a member of the Eclipse Foundation;
- The company needs to have their logo uploaded to the Portal;
- 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)
If all of those conditions are met and the logo is still not showing up, then it’s possible that the project meta-data doesn’t have the correct version control paths specified–this affects whether the committer is considered active by the dashboard.
A project can specify a section of text, links, and a selection of the build technologies employed. Specifying this information makes it easier for members from the community to understand your build. Links can include direct links into the Hudson builds, pages of build instructions, or whatever else you feel will help the community build your project.
A project can specify the types of technology produced by the project. This is specified in rather broad terms like "OSGi" or "Runtime". The various technology types manifest as checkboxes on the edit screen. This information is used to form connections between projects to assist in navigation and discovery.
Note that by clicking on one of the technology types, you will be taken to a page that lists the projects that produce that particular type of technology, along with the summary of their description and project logo (if specified).
There is a lot more information displayed on this page. We'll fill in these details over the coming days and weeks.
Use the Generated Content for Your Project Home Page
If you want to use this page as your project home page, change the contents of your project's index.php file to:
<?php header("Location: http://projects.eclipse.org/projects/your.project.id"); ?>
(with an appropriate substitution of your.project.id, e.g. technology.egit, of course).
Note that the automatically-generated pages will continue to grow, change, and be updated.
Where is Project Metadata Used
Project metadata is used in a few different places today, and usage will continue to expand. Below are a few examples.
- Projects using Tycho, or Maven. The description and project logo are used here.
- Projects participating in the Kepler simultaneous release. We'll add a page that includes descriptions, logos, links to the project plan, and maybe contact information.
The project description is used in a lot of different places. Keep your project description concise; it is a means by which you can encourage people to take a closer look at your project; do not try to describe every little nuance of your project in the description. Note that you can separate out a summary of your description that will be used in lieu of the longer form which will be displayed on the project page.