I’ve been putting a lot of thought into Eclipse Corner lately. We’ve been getting a lot of proposals and submissions lately, and some of them have given me cause to reflect on just what kind of content should be posted on Eclipse Corner. The process today is pretty straight forward:
- The author submits a proposal through Eclipse Bugzilla
- The community comments, based on comments, whether or not the article is worthwhile
- The author submits a draft, the draft is reviewed, and an iterative process of refining the article begins
- At some point the article is peer reviewed, and if deemed acceptable, it is posted
- Kudos and some form of Eclipse SWAG are passed onto the author
Frankly, the process is a little broken. It’s a little too informal for my liking. We try really hard to get articles peer reviewed, ideally by the projects, but a lot of articles make it though merely because the editors like them. At present, there is no release schedule; we just push out articles to the site when they’re deemed ready. Probably the biggest problem is that there is no formal description of what kind of article belongs on Eclipse Corner.
It’s time to provide a little editorial direction. Like everything else at Eclipse, Eclipse Corner is open and transparent. In that spirit, I have some thoughts about what I’d like to see formalized. I invite you to comment.
Here are some thoughts:
Articles should be timeless. Or at least relatively timeless. That is, articles that contain time-sensitive material or are likely to expire in a relatively short period of time do not belong on Eclipse Corner. An article that discusses the ins and outs of some Eclipse API belongs on Eclipse Corner because (apparently) APIs are forever. An article discussing how great EclipseCon 2007 was or even the Europa release probably doesn’t fit.
Perhaps a little on the gray side of things are articles that discuss how to use exemplary products produced by Eclipse products. These aren’t API and so may change and evolve, potentially rendering the content obsolete. My opinion is that despite this danger, this sort of article belongs on Eclipse Corner.
Articles must pertain to Eclipse projects. Ideally, articles are about how to make Eclipse things (like APIs) work. Eclipse Corner is not the place for articles that discuss the specifics of proprietary products or code/products/whatever from other sources. More on the gray side of things would be an article that discusses how Eclipse APIs are leveraged to build a commercial product. IMHO, as long as the article focuses on how to do great things with Eclipse it’s okay; overt advertising of any commercial product doesn’t belong on Eclipse Corner.
Articles should be explicitly associated with an Eclipse Project. I think that this is reasonable and may even be assumed by some. However, there is currently no such restriction. I wonder if it might be too restrictive as there is huge value in articles that span Eclipse projects (using BIRT with RCP, for example).
Perhaps, articles can be explicitly associated with multiple Eclipse projects. Ideally, I’d like to get the PMC or PL from the projects to agree that the article is something valuable that should make it to Eclipse Corner, but I’m concerned about adding one more thing to their list.
Article proposals must be commented on in Bugzilla. Comments indicate interest. If there is no community support behind an article submission, then it might be best to just pass on it. This, of course, raises the question: how do you measure it? My current thoughts are that 3-5 people have to believe that the article is appropriate content for Eclipse Corner. Perhaps some number of committers from the associated projects shoud be included in that number. For example, 4 total with at least one committer from the project.
Push out new articles on a schedule. I’m thinking of lining up the articles on a monthly basis. This would give the editors the ability to properly focus their attention. Also, it would give authors realistic expectation of when they can expect to be published. Given the current volume, one solid article a month is probably reasonable. Any decisions that we make with regard to scheduling would have to change and I imagine that we’d have to accommodate exceptions; there’s no point it artificially holding back an article that’s ready.
Articles must be released under the EPL. This one’s not up for discussion. This is just the way it is. By putting the article on our server, it’s subject to the EPL. The content of the article must be licensable under the EPL. If the article shows code, that code must be compatible with the EPL along with the rest of the content.
I’ve been working on some more mundane things like getting the existing articles into a more consistent format and adopting the Phoenix look, but with 84 articles packed with various abuses of HTML, it’s a lot of work. It’s coming, be patient.
I look forward to hearing your thoughts on the topic.
