From a look over that issue, it looks like the worst of waterfall methodology. Sorry to sound harsh, but it can be observed that the giant spec has NOT been implemented, and as seen in this thread it has actually scared off a potential implementer. That’s counter-productive.
I think what would make a lot more sense than implementing a giant spec, would be implementing a MINIMAL spec, while allowing for eventual expansion with backward compatibility.
For instance: for the first iteration, implement absolutely nothing but:
groups:
“somegroup”
policy => “present”;
Make the “policy” attribute required even though only the “present” value will be allowed, just because that will allow the most flexibility for future changes, while retaining backward compatibility. (E.g. maybe later that attribute will become optional, but the behavior of having the attribute THERE will not change.)
This should be really easy to code, then, and should be immune to bikeshedding.
It could go before or after users in normal ordering; I don’t think it really matters. For the minimal implementation, “before users” makes more sense, but later on “after” could be preferable; either way there are minor trade offs, so flip a coin.
Best,
—Mike Weilgart
Vertical Sysadmin, Inc.
Sent from my iPod