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