On Wed, Apr 20, 2011 at 7:44 PM, Frank Bennett <[email protected]> wrote:
> On Thu, Apr 21, 2011 at 7:16 AM, Bruce D'Arcus <[email protected]> wrote: >> So before I think more on details, is the key to your suggestion the >> "versioned documents" bit? > > That, plus (in a single location) definite guidelines on what should > go into a proposal, and a clear statement of the workflow that leads > from proposal stage to adoption, rejection, or revision. But we have to work with existing infrastructure to track that process of proposal, discussion, and resolution: git repo, wiki, issue tracker. That's one thing. Aside: worth noting that github wikis are themselves just git repositories of markdown files. The other thing is the actual form of proposals. We have previously discussed the possibility of them being accompanied by tests. So anyone have thoughts on how we put this all together? One possible strawman, for example, is something like: - setup csl "proposals" project (per Frank's suggestion) - use the project wiki for the actual proposal text, which maybe is structured in such a way that upon acceptance, both spec content, schema diffs, and test suite contribution can be extracted (??) - proposals tracked and discussed in the issue tracker, with link to wiki page Bruce ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
