Eclipse Project Management Infrastructure

Work in earnest has begun on a replacement for the Eclipse Developer Portal.

We’re being a little ambitious with this new effort. We need to do more than what the current portal does. And we need to make it natural and easy to use. Further, I’ve decided to expand the target audience for the new implementation. It will be more than just a ‘developer portal’, it’s a reimagining of the entire Eclipse Project Management Infrastructure that provides a little something for everybody, including consumers of Eclipse technology.

As a first step, we’ve implemented a representation of projects. For consumers, this will manifest as something very much like the new-and-improved project summary pages (which I’ve been referring to as “project info pages”) for learning about projects and the relationships between projects. For authenticated committers, the page is a little different, featuring an “edit” button which will allow in-place editing of the various fields.

I’ll be showing off our modest beginnings at EclipseCon Europe 2011.

Depending on the type of user, and roles within a specific project, additional menus will appear to provide committer/lead elections, creation of releases, etc. The intent is to make it a one-stop shop for everything a community member needs to do.

In that vein, we’ll be rolling the project proposal process into the new infrastructure. A project proposal is a document that’s maintained by the system, taken through a well-defined process, and eventually turned into a project. Likewise, reviews will be documents managed by the system. One of my bigger frustrations is that too much of our information is buried in documents that are not easy to mine for information; by keeping this information in the system, we’ll be able to do clever things like reuse information from one review to the next.

I envision a simplification of the release review process. Instead of making releases and their corresponding review separate things, I intend to join them. A project member can create a “release” record for their project in the system. A release keeps track of basic information like the name/number, date, and type of release. Then we’ll tack on some other obvious information like a description of the release (what’s included), a link to a new and noteworthy document, screenshot images, a Bugzilla URL, link to the IP Log, etc. With this kind of information, the release record itself can serve as the review documentation and be taken through a workflow that doesn’t depend on checklists and email exchanges.

By connecting screenshots directly to a release record, we may be able to finally address Bug 214277 (by attaching screenshots to a specific release, we can generate a master screenshots page that is more-or-less guaranteed to be up-to-date). We can go one step further: if we capture the location and description of downloads, URL for update sites, and Eclipse Marketplace Client metadata, we can use that information to automatically generate a download page for each release.

I think is important is that we give projects the option to keep doing what they’re doing. I think the new project info pages (and the corresponding implementation in the new system) can serve well as a default project website. This will certainly make it much easier for new projects to get started. But projects that want to do something a little more custom will still be able to do so. The same holds for the automatically-generated downloads pages that are still currently in the dreaming stage.

It’s still very much early days on this effort and we’re not quite ready yet to show our results. While Nathan works furiously to show some early results, I’ve been working my way through the bug backlog against Portal. Over the next few days and weeks, I’ll be entering some new bugs to track the development of the various aspects of the new infrastructure (which we’ll use to solicit your direct input). Then, using the the early work as a guide, we should be able to get a good sense for development velocity and establish an actual plan and schedule. Stay tuned.

See you at EclipseCon Europe!

About these ads
This entry was posted in EDP. Bookmark the permalink.

3 Responses to Eclipse Project Management Infrastructure

  1. Bernd says:

    Cool. will all of that be based on Skalli?
    see you next week
    Bernd

  2. Pingback: Eclipse Project Management Infrastructure Technology Choice | Eclipse Hints, Tips, and Random Musings

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s