SMIRNOFF committee policy/structure changes? | JW | I made this committee largely with placeholder rules and no limitations on what the committee could do, with the intent for the first committee actions to be “coming up with better rules” Do want to have monthly-ish meetings? JC – Could go faster than a month - Like a 48 hour turnaround on slack? Then monthly meeting could be bigger picture discussion. DM – Three days may be tricky, would mean that people can’t take 3 day vacations. Could do “no objections within” whatever timeframe devs need, a week or a month or… … JC – Could make a larger group of stakeholders? Like FF users, OFFXML parser writers. And the categories of things we might get feedback on include (1) clarification, (2) affects existing behavior, (3) experimental, (4) things we think we need MT – These are good categories. JW mentioned “breaking parsers” and “spec changes” as if they were synonymous. But there are spec changes that wouldn’t break main-line FF parsing. Right now if we ship a FF with LJPME, WBOs, vsites (things that are already in-spec) most parsers will break because they never bothered to implement it. JC – We can put changes into categories and push proposals to be more minimal. JW: The really scary/most to avoid spec change is ones that change the meaning of a prior force field, e.g. changing energies from parsley. But adding a new keyword: NBD. JC: So new changes should require categories, alters processes for consideration and notification. Documentation clarifications straightforward, for ex. MT – There’s already a section in the SEP template where you have to identify effects. JW: Driver should identify category it’s in.
Are we happy with committee composition? Should all decisions continue to require unanimity? DM – Instead of “explicit yes”, how about “absence of veto”? JC – Since folks travel, how about leaving time for asynchronous feedback? DM – That’s a good idea. JW – Could have a system where “no feedback” for two consecutive meetings means “implicit approve” MT – Would prefer some system where “3 yeses and no feedback for a while means 4 yeses”. DM – I propose “we try to have monthly meetings but if we don’t get feedback for a while then assume yes” LW – I think JC was saying that meetings should be used primarily for unblocking. JC – Yes DM – I think the GH issue feedback needs to be clear for asynchronous communication to work. JC – GitHub PR tools can help here. So we can explicitly approve, comment, or request changes. Can also just require “no negative votes”. LW – Two weeks for time bombs would be good. JW – S (General) – Changes are approved with 4 “Accepts”, “2 accepts + 2 weeks, and no request-changes”, and if there’s a “request-changes” that isn’t resolved, that becomes an agenda item in a meeting (General) – We’ll have a standing meeting each month and will just cancel if there’s nothing to discuss.
Should we be expected to read spec proposals ahead of time? Or set aside in-meeting time, Amazon-style
|