Jump to: navigation, search

Difference between revisions of "Committer Community"

Redirect page
(Redirecting to Development Resources)
 
Line 1: Line 1:
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.
+
#REDIRECT [[Development Resources]]
 
+
So here, we brainstorm. Ideas present here do not represent official policy. Once ideas are formed here, we'll move them into Bugzilla.
+
 
+
= 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:
+
 
+
*Forums - a new web-based interface is in "beta" stage now. See http://www.eclipse.org/forums/ (problems and suggestions are being tracked in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=284281 Bug 284281])
+
*Something like [http://eclipse.dzone.com/ EclipseZone], or [http://stackoverflow.com/questions/tagged/eclipse Stack Overflow]  
+
*Embedding a newsgroup client into the Eclipse packages. Such a client has been proposed (and a lot of code already written); see&nbsp;[[Newsreader|Newsreader]]. <br>[https://bugs.eclipse.org/bugs/show_bug.cgi?id=285711 Bug 285711] is tracking the proposal of the code as a component of ECF.
+
 
+
== 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).
+
 
+
* <strike>Creation review documentation seems extraneous. Why not just use the project proposal?</strike>  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?)
+

Latest revision as of 14:36, 18 April 2013