Managing issues

I'd like to propose that we introduce a new status "Deferred" (or perhaps "Long Grass") for issues where we think it's a nice idea, but we believe that a 4.0 specification would be viable without it. Basically, anyone is welcome to raise a concrete proposal to implement the feature (preferably with tests!) but unless they do so, we'll ignore the issue. They will appear on the GitHub list as closed issues rather than open issues. The idea is to give us a better oversight of the work that we need to do before we can declare victory, as distinct from ideas that we would like to implement if we ever get around to it.

I can see us moving a large number of issues into this category, examples being

1111 - xsl:pipeline
1006 - regular expressions, word boundaries
996 - regular expressions, look(ahead|behind)
959 - unix time
938 - canonical serialization
735 - local functions in XSLT
716 - generators
573 - node construction functions
564 - sorted maps
451 - multiple schemas
358 - indentation whitespace
148 - get  the type of a value

etc etc.

I would stress that moving an issue into this category doesn't mean we have decided not to do it. It means that we have decided we don't absolutely need to do it, and we intend to take no further action unless someone picks up the work and volunteers a concrete proposal.

Michael Kay
Saxonica

Received on Wednesday, 15 May 2024 08:20:43 UTC