New process for getting trees in / out of synthesis

[kcranston]

There has been a huge amount of discussion about how to make it simpler for users to add trees to synthesis. I've created a summary of the issues and proposals on the wiki. Review requested. @mtholder @jimallman @jar398 @bredelings @josephwb @snacktavish

Comments welcome on this issue, or there is also a dump of the text in google docs for ease of commenting on particular parts.

I would like to get the design finalized and implemented before the Chicago workshops (Oct 21-23).

[jar398]

Mark's suggestion is similar to what I was starting to prepare (but won't bother with now). The 'truth' about whether a tree is supposed to go in next synthesis resides in the collections, so what the nexson says about that, if anything, is ignored. But the 'truth' about the reason(s) for not including, regardless of whether the tree is included, go in the nexson. The implementation cost is that the UI will have to know what the collection(s) say about inclusion before presenting information to the user about a tree's current status (which is the composite of the two information sources); it can't just look in the nexson because that won't say anything about inclusion. But I think we are paying that cost anyhow. The synchronization / consistency / 'drift' issue is therefore addressed by just stating that it does not exist. Inclusion, and having reasons not to include, are simply orthogonal. The complete set of options (states = inclusion state X list of reasons to exclude) would show up as considerable UI complexity. But the same structural idea works with a smaller number of nexson states, maybe even as few as are in the 'Proposed new workflow(s)' section. There are several approaches: rich state space with rich UI, sparse state space with sparse UI, rich state space with sparse UI (because only a few states are used).

[jar398]

#684 bears on this I think? That is, it proposes another way to make it easier to propose a tree.