I'm biting my tongue, Carlo.
The difficulties aren't primarily with the code, which can be (and
on occasion has been) amended to overcome those types of
problems.
However, none of our volunteers has considered it appropriate
or within the scope of their skills or interests to, for instance,
document it; so it's pretty closely held within a small group.
On Tue, Feb 16, 2010 at 2:30 AM, Carlo Traverso
<traverso@posso.dm.unipi.it> wrote:
>>>>> "Walter" == Walter van Holst <walter.van.holst@xs4all.nl> writes:
Walter> On Mon, 15 Feb 2010 13:26:09 -0800, don kretz
Walter> <
dakretz@gmail.com> wrote:
>> or not, making quite clear. We can't recast the decisions made
>> in the past, but we need to do a better job of learning from
>> them and dong better. Sooner would be nicer than later. Hence
>> rfrank's project.
Walter> wondering to what extent parallel P1 rounds might be
Walter> helpful. I find P2 proofing exceedingly boring because of
Walter> the small number of errors that are left to be fixed in
Walter> texts that are well-scanned and well-proofed in P1. I
Walter> can't imagine how mind-numbing P3 will be if I ever become
Walter> eligible for that 'status'. I can imagine that only having
Walter> to look at the differences between redundant P1 proofed
Walter> texts might be helpful since it would take two independent
Walter> P1 proofers to overlook the same error to have it slip
Walter> through.
This would be simple enough, just allowing a PM to load a set of txt
files and a dummy proofer name in one of the projects columns. The
administrators (having DB access) do this if asked, I suppose with a
script (I have one in the test site). Another improvement would be to
allow a PM to skip a round; this too is reserved to the few, overloaded
administrators, but it is just changing a flag at one point in the code.
Walter> Another potential improvement might be to make texts
Walter> available to the next round on a per page basis instead of
Walter> having to wait for all pages to be finished in the
Walter> previous round.
This might be trickier, since the whole philosophy of DP code is based
on rounds and per-round permissions. It would require at least to start
a new test DP site in which new changes in the code are made and
extensively experimented in a live environment. The current test site
is used for testing features that are potentially disruptive, and is
inadequate for live testing: it is for alpha testing, a beta testing
site would be necessary, or probably more than one.
rfrank's test site at fadepage has abandoned the round philosophy, but
is not derived from DP code, it is reimplemented from scratch.
Walter> Aforementioned suggestions may be silly, feel free to
Walter> point out their silliness.
Not silly at all; I believe that the main problem of DP is its
rigidity, the "one size fits all" philosophy, that is partly in the
code, but mostly in the procedures, and is necessary in a huge
structure. Smaller DP sites like DP-EU and DP-CAN have shown a more
flexible structure, so I believe that a confederation of different DP
sites, sharing a common aim and a common codebase, but different local
laws and software configurations, and a loose coordination, would be a
better model.
Carlo