The Text Outline Project: a proposal for a pilot project
May 13, 2006

Please consult the Textop summary, the Collation Project summary, and the summaries of the other three projects for essential background.

The following document can now be edited on the pilot project wiki.

Why a pilot project

If we proceed to discuss and plan matters such as governance and software design, when only one person has a very clear idea of the main proposal on the table for the Collation Project, all the other participants are very apt to unduly depend on that one person.  If we quickly start up an exploratory "test" Collation Project, focusing on a handful of texts, making use of a wiki, we can introduce potentially dozens of people to the relevant operational concepts and principles efficiently and effectively.  Moreover, a test wiki could also be used to prototype other projects.  Note: the project does not aim to use wiki as the main software for any project.

Goals of the pilot project

The goals of the pilot project are:

  1. to introduce a whole group of people to the concepts, principles, and challenges of the Collation Project and of expert-managed, strongly collaborative work generally--making this group of people better suited to make recommendations about the ideal principles, governance, procedures, and software of a mature project;
  2. actually to start the process of working out the ideal principles, governance, procedures, and software;
  3. actually to start the work of writing the outline (although we might decide to scrap this initial work altogether, if necessary); and
  4. to prototype, and draft rules for, the Analytical Dictionary, Event Summary, and Debate Guide projects as well.

Goal (1), if achieved, would have the further benefits of improving the basic decisionmaking of the project--which is probably the most important benefit of all--thereby reducing messy retreads down the road.  Goal (1) would also help legitimize community principles.  Designing the software and settling upon (as opposed to merely discussing) policies in the absence of relevant specific experience might well produce imperfect policies that have inadequate buy-in from the community.

In deciding whether to proceed with this pilot project, participants should consider any possible disadvantages.  One is that the work done by the pilot project might turn out to be substandard for a whole variety of reasons, and failure to use that work might disappoint the contributors to the pilot project.  Another is that it might be the case that, with just a bit more explanation, more people will be able to understand the project adequately, so that setting up a wiki for a pilot project will be seen to be an unnecessary distraction.

Probably, on balance, the pilot project is advisable simply because this way we can avoid many possible mistakes in design of the software (especially) but also of project governance, procedures, and principles.

How to start up the Collation Project pilot

First, bear in mind that the organization of and planning for Textop should not wait for this pilot project.  It will proceed and be refined as pilot project participants gain essential practical knowledge of the issues involved in setting up the Collation Project on a large scale.

The pilot project need not be perfect: it should "push" people to understand the challenges of this sort of project.  But it should also be tractable, or a priori feasible.  For that reason, we should probably focus on just a few texts in just one or two subject areas.  Since Textop's director, Larry Sanger, is a philosopher, and since philosophy concerns the most general of subjects, it will probably be most tractable to do several philosophy texts.  Moreover, since the project's aim is to chunk texts in their original language, and we cannot easily test the plans for internationalization using a wiki, the plan would be to collate several works in English.  Here is a suggested list from which participants might select a subset:

We will set up MediaWiki on  (Actually, we have already done this.)  Then we might post messages to a number of philosophy mailing lists, and contact some people individually, and hopefully a quorum of able philosophers will appear as a result of that.  Bear in mind that a quorum, for pilot project purposes, might actually be quite small--as few as three or four active people.  Of course, more would be preferred.

To avoid (hopefully) the necessity of teaching wiki software, the message will urge people who are familiar with wiki software to get involved.

Another subject for which it might make sense to start up a pilot project would be history, simply because a chronological outline will be so different from an outline of "timeless abstractions" based on philosophical texts.  If participants think this is a good idea, we will have to call upon historians to produce a list of a history books to collate: a wide variety of good, public domain, English language histories.  If a historian or two would like to provide such a list, we'll include it on this page; Gibbon and Hume might be good to include.  (Mail larry.sanger at dufoundation dot org.)

How to use the wiki for the Collation Project pilot

Note: the project does not aim to use wikis as the main software for any project.  The only reason we'd use a wiki is that a wiki can be used to do something like what is planned for the Collation Project, and MediaWiki is pretty easy to set up.  So it's good testing software for our purposes.  More appropriate software for the long term is described elsewhere (and see also the screenshot).

In any event, the outline itself (just the headings: see glossary if necessary) will live either on one wiki page, or separated into about ten (i.e., the number of second-level headings).  Each node in the outline will be made into a wiki page title; so, if a node heading reads "legal excuses" then there will be a wiki page titled "legal excuses", and the text chunks associated with that node will be copied onto the "legal excuses" wiki page.  This requires that, if anyone wants to edit the wording of a heading, he or she will have to change the wiki page title too.  But this is easy enough to do using MediaWiki.  Besides, the other option, of giving the node content pages unique numerical identifiers and displaying the node heading as alternate text on the outline page, is too complicated, and it would require that node content page titles be numbers, which would be confusing.  For a pilot project--again, the use of a wiki is only for test purposes--this is an imperfection we can live with.

Larry Sanger might upload his work on Hobbes' Leviathan into the wiki, as a highly editable starting point; it is very much a work in progress.  This assumes that the work is not so completely hopeless, on the view of Hobbes experts, that it would be more efficient to scrap it altogether.  If so, that's what we'll do.

We will not have fine-grained access controls, but as a socially-enforced, "honor principle" rule, we will require all participants in the pilot project to use their own real names, and we might require some minimum benchmarks--to be determined--in terms of philosophical training and background with a text.  Then again, in the interests of a vigorous and active pilot, we might not.  At any rate, we will have some expert editors even for the pilot project.

Furthermore, the texts themselves should be uploaded from their source, assuming they are all in the public domain in a digital format (e.g., from Project Gutenberg), and when a certain part has been chunked, it is marked as chunked.

Using the wiki to prototype of other Textop subprojects

Another reason to use a wiki for the pilot project is that it would provide a simple interface whereby people could prototype the other three projects.

To explain and explore fully all the various possibilities of execution of the Analytical Dictionary Project, the Event Summary Project, the Debate Guide Project, and any other projects that come down the pike, as well as design of standards for markup of texts, we would do well to show examples of what we have in mind.  We probably have slightly different notions of what, for example, an analytical dictionary entry should look like, and how it might fit into the outline.  Before we settle upon any standards, let alone choose or make requirements for any software, we should hash out these differences with a few prime examples.  The same goes for event summaries and debate guides.  But, unlike the Collation Project's outline nodes, these entries, summaries, and guides are relatively modular, and many, perhaps most, of the interesting questions about format, procedure, rules, etc., concern individual entries, each of which could fit on a single wiki pages.  Of course, we probably will not want to use a wiki for these projects in the long run, because each of these projects will probably have its own unique requirements that would make it advantageous to have specially-written software.  But a wiki is good enough to get a good start.

When, or soon after, we begin recruiting philosophers for the Collation Project test, we might also recruit other classes of people to work together on standards for the other projects: lexicographers and word lovers for the Analytical Dictionary Project; journalists and citizen reporters for the Event Summary Project; and rhetoricians, informal logic teachers, policy wonks, and others for the Debate Guide Project.

Pilot project management

For the Collation Project test, a new "textop-en-phil" mailing list (Textop philosophy in English) will be set up, where the pilot project will be organized and discussed.  Whenever we start recruiting for the other subproject pilots, we'll set up mailing lists for each of the other subprojects.

Each pilot project will launch with a certain set of rules and procedural guidelines, which can be discussed and modified as we proceed.  Draft of these rules will be posted on soon.

Project management can take place as appropriate via the wiki, the mailing list, and e-mail.  But in any case, for the Collation Project, for every text we commit to collating, we will find at least one philosopher who teaches and specializes in that text, and that person (or those persons) will be the text's editors.  Individually, the editors will resolve disputes about how a text is to be chunked, what summaries are given, and will represent any people working on the text for purposes of working out how the outline shall read.  Since there will be one common outline for all texts, the collection of editors will have the final say, by vote, on questions of how the outline shall read.

For the other projects, we will find pilot project editors who will direct (or co-direct) work on their projects.

More nuanced descriptions of project management are expected to result from this pilot project, and editors and participants should feel free to "rewrite the rules" of their relationship as they feel necessary.  In the event of really difficult, acrimonious disputes, the Project Director reserves the right to articulate the solution (typically a compromise), with input from participants and the Textop Advisory Committee.

How to report and use results

It is expected that pilot project participants will rapidly form their own opinions about the future shape of Textop.  No doubt, while the pilot project is under way, some discussions will take place on the "textop" mailing list which will lead to adjustments and refinements in project design and direction.

The pilot project will come to a designated, well-defined end, but we cannot say what this will be until after some more discussion.  Near its end, or afterwards, pilot project editors and the Textop director will compile a list of "lessons learned" and recommendations.  What follows are some questions to answer, or issues to address, in formulating these recommendations:

Special note about participation in the pilot project

While it can be expected that some of the most valuable participants in the future Textop will also participate in the pilot project, participation and leadership in the pilot project will not confer any special leadership rights in the future (non-test) project.  This is because we can easily anticipate the following situation: late-arriving experts are extremely impressed by the growing Textop community and the examples produced, though they were not involved in the pilot project.  They include some authorities who stand head and shoulders above current participants, as authorities on a text (or on lexicography, or whatever).  But Textop should be a meritocracy, not a rule-of-the-first-to-arrive.  As a result:

The pilot project's purpose is not to settle on the future management and policies of Textop.  It is to produce a set of intelligent recommendations for the project.  Future management will likely be determined only after the pilot project has made its recommendations about governance, and initial policies will not likely be adopted until after management has been installed.

Pilot project testers should bear that in mind.  That said, of course many participants in the pilot project might well find themselves leading the future project, due to their own expertise and energy.  We simply need to underscore that this cannot be an expectation.

Back to home page