Thoughts on future spec changes

With 1.0 out the door, I’ve a proposal for changes going forward. Any
changes:

  1. must be accompanied by tests, which by definition include not only syntax
    additions, but also input expectations. This is to ensure the full circle of
    use case, csl syntax, input and output are considered.

  2. must be implemented by more than one project. So if Andrea proposes
    something, for example, Frank needs to implement it too.

Both are intended to ensure the spec remains practical to implement.

The rules would be simpler for simple changes like variable additions of
course.

Thoughts or additions?

Bruce

“Bruce D’Arcus” <@Bruce_D_Arcus1> writes:

With 1.0 out the door, I’ve a proposal for changes going forward. Any changes:

  1. must be accompanied by tests, which by definition include not only
    syntax additions, but also input expectations. This is to ensure the
    full circle of use case, csl syntax, input and output are considered.

I totally agree.

  1. must be implemented by more than one project. So if Andrea proposes
    something, for example, Frank needs to implement it too.

Both are intended to ensure the spec remains practical to implement.

The rules would be simpler for simple changes like variable additions of course.

Thoughts or additions?

Ok even for the secod, as long as this rule is not used to stop the CSL
development. That is to say, two implementations are better than one,
but I think the one implementation is better then nothing and probably
enough most of the time. The transition from CSL 0.8 to CSl-1.0 seems to
me an evidence of that.–
andrea rossato

OK, maybe there’s a qualitative difference in what “one” means though.
There’s a difference between a second implementation that agrees with
the change, but just doesn’t have time to implement it, and one where
they refuse to implement it because they think it a bad idea.

I guess we’re fine if we continue to operate on the consensus model
we’ve been using.

Bruce