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. 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