A copy of the official proposal can be found at http://www.people.cornell.edu/pages/mew66/gsoc.pdf.
I'm Mike Wacker, Assistant Web Editor for The Cornell Daily Sun. Over the past school year, The Sun has used a web publication system, codenamed MustRun, to manage our content online from when the story is assigned to when the story is finished. I coded the group of modules that are MustRun, and other web staff on The Sun have contributed to this project as well. Currently, I am working on the second version of MustRun, and I've found that there are so many things that can be done with this version, especially after getting feedback from the current version which has been in use for almost a year.
Thus, I thought I should mention this as a potential Google Summer of Code proposal. Such a project would help expand Drupal's reach in the realm of journalism. The Sun built MustRun in the first place because it could not find a comparable contributed module. As newspapers consider switching to Drupal, it will be important that they can have a module out-of-the-box to help manage the publication of their content via the website. This is especially important for those publications that are limited in terms of their ability to create custom modules or modify contributed modules to meet their needs.
First, I should start with an idea of how MustRun works. In MustRun, our editors at first will create story assignments online. Staff writers will then log on to the website and take these assignments. They then put the story on the website and mark it as finished. There is also a way to give people access to the website to revise the articles, but in the end the editors will mark the story as ready to publish. Then, when the online edition of The Sun is ready to go out, one person clicks one button and the entire online edition goes out on our website.
For the second version of MustRun, I am going back to some problems I have looked at before and retackling them (as I often see a better way to do things now that I have worked with Drupal more), and I am also looking to incorporate new features. Here are some of the more important challenges:
Permissions frequently change with a node. All writers get access to pick up an assignment, then one writer who picks it up has access to it, but once the node is finalized, only editors should have access to it. Others can access it to revise the article, and of course there could possibly be a hierarchy of permissions for the editors, too. And of course, only sports writers should pick up a sports story, some stories should not be picked up by new writers, etc. Drupal's node grants have gone a long way in solving these challenges, but I am also experimenting with other ways to do permissions. For example, I tried using a form that programatically updates a node when a writer checks a checkbox to pick up the node and then submits the form. This lets me use PHP and the Form API to control permissions on an even finer level.
Writers should get notifications if a story is available to pick up, if an editor directly assigns them a story, etc. Also, editors may also benefit from some email notifications here and there.
Articles just don't have a date they are published. They have a due date; there may also be an associated event which occurs at a certain time. Thus, not only must these dates be added, but they have to be integrated into the system.
It's especially important that the user interface to access all content in MustRun be intuitive and easy to use. From one calendar, users should be able to find content to pick up, view content they have picked up, and see the dates for all relevant content, etc.
Ease of Use:
Along the same line, a simple staff writer should have a very easy time using the system. But this matters a lot for the editors, too. They're managing all this content in MustRun, and they may not want to send an email notification for this article, change a setting for feature X, etc. As the feature set for MustRun adds up, the complexity of the administration pages could potentially grow to an unmanageable level. This complexity needs to be managed.
These are just a compilation of my thoughts on the matter. I'm sure I've missed a few things, and I probably will have made a lot of progress on some of the other items before GSoC even starts. But I wanted to put my thoughts out here so I could get some feedback.
Version 1 of MustRun can be downloaded at www.people.cornell.edu/pages/mew66/mustrunv1.tar.gz. Its provided on an as-is basis. Note that the architecture behind it is real esoteric (with changing node types and strange invocations to nodeapi) and has changed to something much more reasonable for version 2. Basically, the architecture is the closest you can get to hacking the core without actually hacking the core, and I needed the mustrun_image module just to make it work with the image module. mustrun_type and mustrun_group are two modules that provide MustRun with two more options on how to do permissions. I also believe that email notifications are spread between mustrun and mustrun_group. Keep in mind, this is the old version, and I didn't know as much about Drupal back then.
The newer version of MustRun in progress can be downloaded at www.people.cornell.edu/pages/mew66/mustrun.tar.gz. It contains all the features that are fully working; some incomplete portions of code have been excluded. Basically, this has three main features: it has the fundamental architecture of MustRun, the ability to clone nodes (for a recurring assignment), and the ability to publish many nodes at once. The way permissions work now are (relatively) simple at this point.