[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Note from the wiki gardener
Thanks for the very good feedback. I can see how “ready-to-vote” would be a handy status to add. But to keep this from getting too complicated, I kind of like the stark simplicity of just three states. We could consider any approved feature, that is not yet locked into the 2.0 spec by TC approval to still be “in-development” because it could still be sent back to the owner as needing more work. I think a downside of adding a “ready-for-vote” state into the workflow is that it could (technically) also be needed/used to indicate a Proposed (2.x) feature is ‘fully-baked’ and ready to be voted on to be promoted to Approved (1.x).
I see the starkly simple lifecycle flow as this:
Proposed feature (state=”under-eval) vote =”y” à Approved feature (state=”in-dvp”) vote=”y” à state=”final”
Proposed feature (state=”under-eval) vote =”y” à Approved feature (state=”in-dvp”) vote=”n” à state=”in-dvp”
Proposed feature (state=”under-eval) vote =”n” à Discarded feature
That said, I’m not married to the starkly simple lifecycle (yet). TC members, please weigh in if you have opinions on the needed “state” values.
Feature (R33) “Glossaries” has been completed and is waiting for the TC’s approval. “In- development” does not convey the right information in this case, another category like “ready-to-vote” would come handy.
Feature (C31) “Allow XML content in <internal-file> element”. Has also been implemented in the DTD by allowing elements from any namespace in <skeleton> and this has been noted in the specification document. Notice that in current XML Schema we don’t have an <internal-file> element. The TC also has to approve this change.