Summarizing what I think you wrote: - I didn't answer your question correctly - You don't have any useful examples of good answers for similar questions - I cannot answer it alone, I need a whiteboard and some other people - I need to write all about how Project Gutenberg operates now, but without mentioning technologies or computing - In order to foster organizational change through improved technologies, I first need to effect that change for myself and other folks who are using non-improved technologies Somehow, I think I'd rather keep emphasizing trying to build improved tools to support stated needs, than try to engage in the process you've tried to lay out. But I'm ready to keep trying to address what you're asking, if you can be more specific about what you are looking for. And: On Sun, Feb 05, 2012 at 03:54:36PM -0800, don kretz wrote:
It's not something you can come up with that way I don't think. It's the sort of thing involving more than one person putting stuff on whiteboards and arguing about it. I was hoping it was something Michael may have been involved with.
Michael didn't have a lot of patience for the technologies behind the scenes, despite being a technoenthusiast. What he wanted, and repeatedly pushed me to do, is to essentially accept anything and everything from everyone (as long as copyright was OK). What I found in at least two well-known such "anythings" (computer-generated audio, and contemporary copyrighted works) was that there was not a sufficient corps of volunteers with interest in those things, versus our more traditional fare of old public domain books. In a third example, we did some work with sheet music. But contemporaneously, some other efforts did a better job at sheet music than we were doing. Plus, they attracted enough volunteers to be successful. Meanwhile, PG just didn't have a good toolset for processing sheet music submissions (including the fact that the master formats are different than for books). This, like with computer-generated audio and contemporary copyrighted works, left me as the sole (or nearly sole) person to process those submissions. The big, huge difference of those examples with our current discussion is that mobile devices have taken over the world. Michael recognized this trend very early. For us, this is a big deal because our core activity is older public domain eBooks. Getting those books to be more functional for mobile devices is an obvious and driving need. Opting out, like we did with the cases above, is not an option. We've made some important steps towards meeting that need, as have been discussed. Such as, RST as an available master format. Auto-conversion to mobile-friendly formats. Mobile-friendly gutenberg.org. Coordination and encouragement for others to use our stuff. And more... What Michael always did (and I usually provided the platform for, as needed) is to say "yes" to anyone with good ideas who wanted to demonstrate them. That continues, to this day. And, historically, there have been a number of people who argued AGAINST innovations, variations, and experimentation. Michael had no patience with such naysayers, and also refused to support squelching the efforts of others. He and I talked about this situation over and over again, since it was common for people to put a lot of effort into talking about what was wrong. Still is, sometimes. Related to that, one thing I know for sure is he did not believe there should be only one type of format (or encoding). Such discussions have been around forever (i.e., since before ASCII). I don't think he would have been against a recommended and documented master format, but only if other alternates were permitte. -- Greg
One way to explain part of it is that it's what you would put together to describe what you do without reference to software, computers, networks, or user interfaces. Entirely about what PG does and nothing about how it does it. It's not easy.
One thing pops out from your list. You put in a bunch of organizational tools requirements and collaborative capabilities when you almost intentionally spurn them now. Do you anticipate a major cultural shift? How easy is it to organize this for other people when you don't see a need for it yourself?
Kinda relates to my initial reaction when revision control came up initially. Install this for DP to use, when it's considered of little value for PG software?
On Sun, Feb 5, 2012 at 3:01 PM, Greg Newby <gbnewby@pglaf.org> wrote:
On Sun, Feb 05, 2012 at 11:26:44AM -0800, don kretz wrote:
Greg, do you have any kind of formal or semi-formal conceptual model of the domain we're dealing with here?
Something like an Object Model in object-oriented software terms; or more obscurely but perhaps a better fit, Object Role Modeling?
I don't, but if you point me at an example conceptual model for something else, which you think is useful, I can try to come up with something similar.
Part of why I didn't start with a requirements list is that my current approach is to look for existing capable software that does a good portion of what we need. No such software will be complete to all our desires, but it should be a good start. This is to avoid writing our own tools from scratch, which (as capable as we collectively are at such things) leads to problems in maintainability and portability.
The basic feature list we'll need for a complete tool is fairly short, and might build upon multiple existing tools:
- able to authenticate users - able to handle different user authorizations, at grainularity finer than "whole site" (i.e., someone might be committer for one eBook, but not all eBooks) - can display differences, merge trivial results, handle forks, and similar source code revision practices - keeps history; can display older versions of files - can be plugged into a transformation system - can use structured metadata (DC, XML, MARC...) to populate information about books - can handle our 38,000 titles in ~1.5M files - can handle books (i.e., "projects") with multiple source files, as is found in HTML+images - a documented API - can work with multiple file types
Conceptual versus functional requirements: - well documented in English - runs on a Linux server - active development community - open source - able to accept code contributions, track feature requests, etc.
I would add these as desirable, but not critical: - exposes the back-end filesystem, for use with other tools - some sort of rating system for most popular items (or, if not, it is required that we can build one upon the tool) - integrate wiki or bug tracking or other features in support of the effort
This is just a quick listing, and is probably not complete. My inclination is to choose a capable and flexible tool (or multiple tools) as the basis for our work, then use our skills to build upon it, perhaps integrating additional existing tools.
Such tools come at different levels of sophistication. Base level tools include mercurial/git/svn. Mid-level tools include Wordpress, Django. Higher level tools include TRAC, Notre DAM, ResourceSpace, Sourceforge, DSpace... I am, of course, quite interested in having an exit path from any selected tools. We don't want to be stuck, if our choice turns out to be limiting us in a few years.
-- Greg
On Sun, Feb 5, 2012 at 11:13 AM, Greg Newby <gbnewby@pglaf.org> wrote:
On Sun, Feb 05, 2012 at 01:36:20PM +0100, Jeroen Hellingman wrote:
Quite an odd-beast, but why not consider fossil?
(http://fossil-scm.org/index.html/doc/trunk/www/index.wiki)
Stand-alone, integrates everything, and could be used on a
book-by-book
base...
There are some super features in that package. I never looked at it before.
Some shortcomings/drawbacks I noted: - filenames are lost, so we'd need an additional layer to map updated files into the collection our readers see and download from (fossil names all files by hashes, and mixes "source" with wiki, bug tracking, etc.)
- single maintainer, seems like (though with some additional contributors, and an opening for us to join as contributors), putting some risk of abandonment
- user control seems simplistic, and possibly not amenable to the hierarchy/meritrocracy approach to "who can commit".
A challenge that many such solutions will have for us is whether to treat each book as a "project," or the whole collection. I am leaning towards each book as a project, but that only works if we can easily share/inherit from existing books. That is, nobody is going to use a Web UI to set up 38K projects to "seed" our efforts.
Anyway, this does look good, but I saw some limitations.
-- Greg
On 2012-02-05 09:56, Greg Newby wrote:
I'm still pursuing the theme of an existing sophisticated code base to enable supporting multiple versions & formats of our eBooks (user-contributed, curated, edited, masters and revisions).
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d