Apologies for not chiming in as much as I'd like on this debate. There have been many excellent comments. This whole discussion is "pre-release," not just about pre-releases. I don't think we have enough information yet to decide how, whether, or for which items it would make sense to have pre-release DP items more widely available. There are various issues involved (technical, moral, conceptual, practical...). Some sort of proof-of-concept is what I'd like to work toward, to try to see what we're really talking about, and whether many (often conflicting) goals could be met. More: On Thu, Feb 25, 2010 at 10:17:19AM -0800, Al Haines (shaw) wrote:
Some of these questions may overlap a bit--bear with me...
Who's going to monitor this pre-prelease page for when projects on it are posted? The WWers? DP? Greg?
Needs to be cron (the Linux/Unix automated task scheduler). If it's not automated, it's not going to achieve anyone's goals. I realize this applies to *removal* not just harvesting.
Will it contain only pre-release text files, or all working files associated with a given project (page scans, illustrations, text, HTML, etc, etc)?
Unknown, which is why I'd like to see an experiment or two before figuring out how, whether, when, etc. I can also envision some sort of "by permission" from the PM in charge of a given project. There are several phases in the DP workflow. I was (always) just thinking about the items that are stuck (i.e., delayed enough to, statistically, be thought of as stuck), but have significant value added and a reasonable level of completion. Somewhat related: page scans have been welcome as part of eBooks for years, but are seldom delivered by DP with a new eBook. (There are a few people who add them separately, later.) Maybe efforts towards getting pre-release items could also be helpful with adding page scans.
If the latter, what's to stop someone from taking those files, getting their own clearance, and submitting them to PG as their own work? Or is DP going to consider that they're, in effect, abandoned projects, and up for grabs? (I can only imagine the reaction that would cause.)
I'm not sure how likely that is, but I would discourage it and attempt to make sure further efforts on an item go back to DP & credit DP. We do reasonably well at spotting duplicate copyright clearances, and could have some README-type info about the "proper" way to take pre-release items and get them completed. My experience is that volunteers tend to honor such requests. After all, there are plenty of items to work on, and the DP front door is open to those with interests in particular items.
Related to a couple of the above questions, would the WWers be expected to check to see if a given submission is one that's also in progress at DP, or would it be a case of first-come, first-posted, and let DP take its lumps?
No, such checks need to be automated. It won't be perfect, but it's doable, well enough to raise a flag at submission time that an item might be a harvested DP item. In our harvesting how-to at www.gutenberg.org, we talk about asking permission, and about honoring requests to not add items to the collection -- even when they are clearly public domain. I don't favor allowing back-dooring of DP in-progress items by non-DP sources.
Rather than dumping who knows how many pre-releases into Preprints, I'd suggest a separate Prerelease page. (Speaking personally, I regularly check Preprints for interesting/doable projects, and have drawn a number of projects from it. I doubt I'd be interested in looking through a raft of ex-DP items, searching for non-DP Preprint items.)
You're solo efforts are amazing and appreciated, but unusual. I don't think the fact that a number (even thousands) of items appear in reprints will result in a lot of separate solo submissions. As others have mentioned, there are any number of sources of items available that motivated individuals could select from. I think that most such people will honor requests to keep prerelease items with DP (including, of course, a link to sign up and get to work on the DP workflow). -- Greg