Difference between revisions of "Committer Community"

From Eclipsepedia

Jump to: navigation, search
(User Community Outreach)
Line 26: Line 26:
 
Presentation-style review documentation is a remnant of the former presentation-style delivery of  review. We rarely hold review calls, and never do a review presentation. Moving forward, review documentation should be in prose form in a plain HTML-format document (no MS Word-generated HTML, please).
 
Presentation-style review documentation is a remnant of the former presentation-style delivery of  review. We rarely hold review calls, and never do a review presentation. Moving forward, review documentation should be in prose form in a plain HTML-format document (no MS Word-generated HTML, please).
  
* Creation review docuware seems extraneous. Why not just use the project proposal?
+
* <strike>Creation review documentation seems extraneous. Why not just use the project proposal?</strike>  We do now.
 
* Review documents should be concise
 
* Review documents should be concise
 
* We should provide a template document
 
* We should provide a template document

Revision as of 14:35, 18 April 2013

On this page, we capture ideas on how we can improve Eclipse for the Committer Community. Actually, it maybe just as accurate to write it as "Committer/Community" in the spirit that making things better for the community makes things better for committers.

So here, we brainstorm. Ideas present here do not represent official policy. Once ideas are formed here, we'll move them into Bugzilla.

Contents

User Community Outreach

Newsgroups are the preferred mechanism for the user community to interact with the committer community. The problem is that it's relatively hard to get started with newsgroups. To start, while you can certainly browse newsgroup archives without specialized software, you really do need specialized software to post (or is there some good web-based newsgroup software that I haven’t searched hard enough for?). Then, before you can post a question, you have to get an id/password; for this you need to create an Eclipse Bugzilla account (unfortunately, when we turn off the password protection, the spam levels get unmanageable). Once you have the account, and your newsreader/poster is all configured, then you need to figure out what group to post to. Of course, we have some very talented and dedicated people who monitor eclipse.newcomer and will point you in the right direction.

Suggestions:

Help Page

Consider setting up a page specifically targeting providing help for the user community (http://www.eclipse.org/help is currently available). Here we can post FAQs, links to relevant resources (like newsgroups), and maybe even a form for anonymously submitting a question to eclipse.newcomer (there may be terms of use and spamming issues to consider)

  • Use project metadata to...
    • provide mapping from project to best source(s) of help for that project
    • link in FAQs

Project Review Process

The project review process needs to be revisited. The purpose of reviews is to provide the broader community with enough information to understand the purpose of the review and the nature and status of the project moving into the review. Further, the process of building the review documentation forces the project leadership to capture, at high level, just what the heck they’re doing. At least for many projects, this is something that they don’t do on an ongoing basis. Without clear direction, a project can wander around aimlessly, ultimately resulting in failure. Periodically taking stock of just what the heck you’re doing—ensuring that the ongoing work aligns with the scope and goals of the project—is good for the overall health of the project.

Presentation-style review documentation is a remnant of the former presentation-style delivery of review. We rarely hold review calls, and never do a review presentation. Moving forward, review documentation should be in prose form in a plain HTML-format document (no MS Word-generated HTML, please).

  • Creation review documentation seems extraneous. Why not just use the project proposal? We do now.
  • Review documents should be concise
  • We should provide a template document

We may want to consider creating some kind of form for capturing review documentation. We could, for example, extract sections of the data and make them more accessible to the community through an RSS feed, Planet Eclipse, etc. A dynamic form with sections for each of the different kinds of review could be cool. We could store the data in our database, where it could be called up and used as a basis for later reviews. The description and scope captured for a creation review, for example, would be useful for a release review. If captured in our database, we could use this information on the project summary pages.

Process Webinars

Record a series of Webinars, targetting project leads and committers, discussing key aspects of the Eclipse Development Process. We can draw on materials from the committer bootcamps run at EclipseCon 2008 (or was it 2007?)