Existing software/platforms
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). Last week I had mentioned looking at TRAC. That is a tool that layers over version control systems like Mercurial or git. I've also been looking at DSpace, which I'm in the midst of rolling out for my campus (i.e., day job), and I will try to ingest all of the files & metadata shortly. However, DSpace does not yet have versioning capability, which I think will remove it from consideration. Two others I'm taking a dive into are Notre DAM (http://www.notredam.org/) and ResourceSpace (http://www.resourcespace.org/about.php). Although these both seem more geared towards photos than eBooks, they do have a suite of transformation capabilities, and accept user contributions. I found a recent comparison of such "digital asseet management" systems here: http://www.opensourcedigitalassetmanagement.org/ It would be great to hear of anything people know of these or other existing systems. At the same time, I know people are looking at using other existing tools that are more general. -- Greg
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... Jeroen. 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).
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).
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? 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
Hi Don, I am getting to like you more and more. Curious what the answer to your question is! regards Keith. Am 05.02.2012 um 20:26 schrieb don kretz:
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?
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
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
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
It's not that you didn't answer it correctly. I didn't ask it in a way that made sense to you. Here's an example from wikimedia. The content is not what would be appropriate for pg and it's more than a conceptual discussion, but you can I think see that several models are discussed for requirements in terms of the problem domain, not the solution technology. Similarly PG might have a document describing the problem/opportunity they intend to address, the nature of the population for whom they intend to address it, and how those people and PG describe ---- model --- organize the scope of what's being addressed, in terms that provide a common, accurate vocabulary. I'm still thinking how to say it. You began to address it, but I think it takes more time to fill out the scope and structure of it.
http://www.mediawiki.org/wiki/Visual_editor/Software_design On Sun, Feb 5, 2012 at 6:35 PM, don kretz <dakretz@gmail.com> wrote:
It's not that you didn't answer it correctly. I didn't ask it in a way that made sense to you.
Here's an example from wikimedia. The content is not what would be appropriate for pg and it's more than a conceptual discussion, but you can I think see that several models are discussed for requirements in terms of the problem domain, not the solution technology.
Similarly PG might have a document describing the problem/opportunity they intend to address, the nature of the population for whom they intend to address it, and how those people and PG describe ---- model --- organize the scope of what's being addressed, in terms that provide a common, accurate vocabulary.
I'm still thinking how to say it. You began to address it, but I think it takes more time to fill out the scope and structure of it.
For example, PG and DP need a vocabulary for discussing the representation of book contents that is familiar, precise enough, and comprehensive enough to discuss how they will represent the book and how PG will interpret their representation. The common language I would expect woutd include paragraphs, headings, chapters, poetry, emphasis, tables, illustrations, captions, viewing devices (screen capabilities and controls), ebook identification, acquisition, distribution, storage, maintenance, ... These are all concepts that have roughly similar meaning to both sides. And you need to agree on the scope and workflow in which you mutually participate; and have a roughly good idea what the participation feels like to each other. When the conversation instead devolves around markup and divs and floats and margins and RCS, you no longer are discussing the problem domain, nor are you using vocabulary that is equally useful and meaningful to both of you.
And of course they are viewing the domain largely through the tools they use for their work; which unfortunately creates a little world of its own that they must train into without much transferable knowledge or skill; and which I think people at PG are completely unfamiliar with. But that's how they view the problem domain. If they make guiprep happy, and see a document on the only output medium available to them for validation (i.e. the browser screen), they have no way to appreciate or adjust to your objections. Their world is A-OK. On Sun, Feb 5, 2012 at 6:48 PM, don kretz <dakretz@gmail.com> wrote:
For example, PG and DP need a vocabulary for discussing the representation of book contents that is familiar, precise enough, and comprehensive enough to discuss how they will represent the book and how PG will interpret their representation.
The common language I would expect woutd include paragraphs, headings, chapters, poetry, emphasis, tables, illustrations, captions, viewing devices (screen capabilities and controls), ebook identification, acquisition, distribution, storage, maintenance, ... These are all concepts that have roughly similar meaning to both sides. And you need to agree on the scope and workflow in which you mutually participate; and have a roughly good idea what the participation feels like to each other.
When the conversation instead devolves around markup and divs and floats and margins and RCS, you no longer are discussing the problem domain, nor are you using vocabulary that is equally useful and meaningful to both of you.
not guiprep, but guiguts. On your side you have gutcheck etc., which they understand fairly well - better than you understand theirs - but now gutcheck etc. is no longer even close to sufficient; where it used to be the entire canon. On Sun, Feb 5, 2012 at 6:52 PM, don kretz <dakretz@gmail.com> wrote:
And of course they are viewing the domain largely through the tools they use for their work; which unfortunately creates a little world of its own that they must train into without much transferable knowledge or skill; and which I think people at PG are completely unfamiliar with. But that's how they view the problem domain. If they make guiprep happy, and see a document on the only output medium available to them for validation (i.e. the browser screen), they have no way to appreciate or adjust to your objections. Their world is A-OK.
On Sun, Feb 5, 2012 at 6:48 PM, don kretz <dakretz@gmail.com> wrote:
For example, PG and DP need a vocabulary for discussing the representation of book contents that is familiar, precise enough, and comprehensive enough to discuss how they will represent the book and how PG will interpret their representation.
The common language I would expect woutd include paragraphs, headings, chapters, poetry, emphasis, tables, illustrations, captions, viewing devices (screen capabilities and controls), ebook identification, acquisition, distribution, storage, maintenance, ... These are all concepts that have roughly similar meaning to both sides. And you need to agree on the scope and workflow in which you mutually participate; and have a roughly good idea what the participation feels like to each other.
When the conversation instead devolves around markup and divs and floats and margins and RCS, you no longer are discussing the problem domain, nor are you using vocabulary that is equally useful and meaningful to both of you.
This is way overkill, http://strategy.wikimedia.org/wiki/Product_Whitepaper but contains a discussion of some of the structures and processes they have and how they see them. I imagine PG has some of the same statistical resources. It would be interesting to see what PG has considered important enough to measure, and how they interpret the measurements.
On Sun, Feb 05, 2012 at 07:10:05PM -0800, don kretz wrote:
This is way overkill,
http://strategy.wikimedia.org/wiki/Product_Whitepaper
but contains a discussion of some of the structures and processes they have and how they see them.
That's a really great document. Very relevant for some of DP's retention and recruitment challenges, I think.
I imagine PG has some of the same statistical resources. It would be interesting to see what PG has considered important enough to measure, and how they interpret the measurements.
(We don't have much, other than statistics we could garner from our posting messages. Nothing at all like the studies that were so helpful to the Wikimedida planning.) But now I think I know what you are suggesting: strategic planning. This is a definite shortcoming of PG. We did fire up a "planning" mailing list a few years ago, and collected some good ideas. But with Michael at the helm, there was a definite lack of majority rule. Karen raised organizational structure and leadership as a topic, and it is related to strategic planning. Here is something the group might wish to consider: Let's imagine we have an opportunity to do some strategic planning. We could even swing a modest budget for planning grants and face to face meetings, meet-ups, and other structure. How would you wish to proceed, and what sort of involvement do you envision for yourself? While you are thinking about that, give some thought to how your role and level of engagement could change, for better or for worse, as a result in shifts in emphasis at PG. How might we attrace more readers, volunteers, and content (if that is, indeed a goal)? What metrics for success? The linked document did a pretty job at such metrics. Like PG, Wikimedia is dependent on the good will of volunteers. Largely unlike PG (though more like DP), a constant influx of new talent is a major element of their success. Ideas welcome. -- Greg
Hi Don, You are ahead of me. I am working on a thread "A New Approach" that will discuss this missing component. a Specification. regards Keith. Am 06.02.2012 um 03:48 schrieb don kretz:
For example, PG and DP need a vocabulary for discussing the representation of book contents that is familiar, precise enough, and comprehensive enough to discuss how they will represent the book and how PG will interpret their representation.
The common language I would expect woutd include paragraphs, headings, chapters, poetry, emphasis, tables, illustrations, captions, viewing devices (screen capabilities and controls), ebook identification, acquisition, distribution, storage, maintenance, ... These are all concepts that have roughly similar meaning to both sides. And you need to agree on the scope and workflow in which you mutually participate; and have a roughly good idea what the participation feels like to each other.
When the conversation instead devolves around markup and divs and floats and margins and RCS, you no longer are discussing the problem domain, nor are you using vocabulary that is equally useful and meaningful to both of you. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Hi Greg and Don, I will allow myself to step in here. One of the missing components in these discussions is what is called a specification. Greg you say this is what I want to do and want a tools that exists for it. We already have this. How do we make it better with other tools or changing things. But, from the perspective of a professional programmer al this is far to vague to do the proper analyses needed. Don you want the correct professional specification so that you can properly modify or design the system Greg wants. I know Don you go for the tools and technologies at a later point. Well you are going to have to meet in the middle. 1) Greg most likely will not be able to supply the Models. But, he can and has in a earlier post stated what he is think of. 2) Don you are going have to take what Greg gives you and develop the Models from there. 3) Don has already i identified that what Greg wants can not be done with a single tool or technology. Yet, it requires a collaboration thereof. 4) Greg is worried about access to the system and that not all understand the tools and that a user can mess things up. 5) don knows how to bring things together So what is need to connect the dots. As a brainstorming idea something as a man in the middle: 1) a user authencates with the tool 2) the use accesses the data via this tool The advantage: 1) is that a user does not need know how a VCS works or which we are using. 2) the you server does not have direct access to the servers(can not mess things up) 3) we can use use any tools needed to kept things working smoothly 4) we can guarantee the the data is consitent 5) we do not need to reinvent the wheel, we just need to build a chasis regards Keith. Am 06.02.2012 um 03:04 schrieb Greg Newby:
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.
participants (4)
-
don kretz -
Greg Newby -
Jeroen Hellingman -
Keith J. Schultz