Much of the activity of the TC in the past week has been devoted to discussing and sometimes arguing about two pending resolutions: Location of Interop Tests and Extended Maintenance (links below). While there has been a lot of IRC chat, and back and forth on the gerrit reviews, it has resulted in things moving forward.
Since I like to do this: a theme I would identify from this week's discussions is continued exploration of what the TC feels it can and should assert when making resolutions. This is especially apparent in the discussions surrounding Interop Tests. The various options run the gamut from describing and enforcing many details, through providing a limited (but relatively clear) set of options, to letting someone else decide.
I've always wanted the TC to provide enabling but not overly limiting guidance that actively acknowledges concerns.
Location of Interop Tests
There are three reviews related to the location of the Interop Tests (aka Trademark Tests):
- A detailed one, based on PTG discussion
- A middle of the road one, simplifying the first
- A (too) simple one
It's looking like the middle one has the most support now, but that is after a lot of discussion. On Wednesday I introduced the middle of the road version to make sure the previous discussion was represented in a relatively clear way. Then on Thursday, a version which effectively moves responsibility to the InteropWG.
Throughout this process there have been hidden goals whereby this minor(?) crisis in policy is being used to attempt to address shortcomings in the bigger picture. It's great to be working on the bigger picture, but hidden doesn't sound like the right approach.
Tracking TC Goals
One of the outcomes from the PTG was an awareness that some granular and/or middle-distance TC goals tend to get lost. The TC is going to try to use StoryBoard to track these sort of things. The hope is that this will result in more active and visible progress.
A proposal to leave branches open for patches for longer has received at least as much attention as the Interop discussions.
Some talk starts on Thursday afternoon and then carries on intermittently for the rest of time^w^w^w^w^wthrough today. The review has a great deal of interaction as well.
There's general agreement on the principal ("let's not limit people from being able to patch branches for longer") but reaching consensus on the details has been more challenging. Different people have different goals.
What's a SIG for?
Discussion about renaming the recently named PowerStackers group eventually migrated into talking about what SIGs are for or mean. There seems to be a few different interpretations, with some overlap:
- Upstream and downstream concern or "breadth of potential paricipants".
- Not focused on producing code.
- Different people in the same "room".
- In problem space rather than solution space.
None of these are really complete. I think of SIGs as a way to break down boundaries, provide forums for discussion and make progress without worrying too much about bureaucracy. We probably don't need to define them to death.