Add minutes for 2016-07-03 breakfast meeting

diff --git a/meetings/20160703/minutes.txt b/meetings/20160703/minutes.txt
new file mode 100644 (file)
index 0000000..c8eec37
--- /dev/null
+++ b/meetings/20160703/minutes.txt
@@ -0,0 +1,109 @@
+Several members of the TC met after breakfast to discuss planning
+tomorrow's BOF; discussions diverged into general TC issues.
+
+Present:
+Didier Raboud 
+Andreas Barth 
+Philip Hands 
+Sam Hartman
+Tollef Fog Heen 
+Keith Packard
+
+
+Tomorrow, we want to focus on giving people time to comment.  Didier
+will send slides to the list for comment.  Focus on what is the
+TC--constitutional role, involvement for dispute resolution, discussion
+of mediation.  Discussion of open issues.
+
+Prompt open discussion of how to get new members, what we're looking for.
+
+action: Didier to send BOF slides to list.
+----------------------------------------
+
+We then discussed ways in which the TC could be improved.
+
+Sam expressed frustration that internal processes make it difficult to
+get work done; frustration when email goes into a void.
+
+Philip talked about how it's very common to have 30 minutes of time.  If
+you can make a concrete step forward in that time, it's good.  If you
+can't, then you may have lost state and context by the time you get
+back.
+
+We discussed when votes are needed and when action like Phil's closing
+of the cross-tool-chain bug is appropriate.  There was a reasonably
+refined consensus of those present that votes aren't needed when actions
+can be undone easily and don't involve exercise of constitutional power
+like overriding a maintainer.
+
+Keith discussed similarity to the UI design consideration that having
+easy ways to undo actions is better than a required confirmation step.
+
+We believe that making it clear in such actions that when a vote isn't
+taken/people are guessing at consensus, the issue can be reopened.
+Keith pointed out that's true of all bugs.  Several thought it was
+explicitly important to point out in these cases.
+
+There was consensus that we want to be sensitive to requests from TC
+members and from involved outside parties requesting a vote in a
+particular case.
+
+
+We also discussed email handling.  It sounds like we'd like to try and
+read email within a week, and get reasonably fast turn around time for
+comments.
+As time progresses, the bar for objections should be raised--for
+example, by two weeks the bar for raising an objection should be
+significantly higher.
+
+Members discussed frustration when objections have been raised late in
+the process (or after the process) in the past.
+
+we discussed  that there is value in a community this small of sending
+messages of the form "I read that; makes sense," rather than just
+objections.  There didn't seem to be a consensus on media.  Some members
+discussed IRC +1s, others pointed out that IRC was unreliable.   There
+was some concern that replies to email might clutter bugs and lists, but
+people seemed to believe that was acceptable.
+There was consensus in favor of such agreement being in public rather
+than on the private list.
+
+
+----------------------------------------
+
+The committee discussed menu system policy.  Part of the TC decision was
+implemented in the policy NMU.  However, another part has not yet been
+implemented.  Didier expressed frustration with the process.
+
+There was agreement of those present that if we have a patch
+implementing the rest of the decision, we should be able to find a way
+forward.  Andreas said that the policy process has stalled and there is
+a BOF later in the week to discuss.  He said that as a policy maintainer
+that if he had confidence a patch represented the TC decision, he would
+feel comfortable committing that patch.
+
+action: Didier to figure out the state of the patch proposing to
+implement the rest of the TC decision.
+
+action: Didier and Andreas to figure out a process for moving forward.
+
+
+----------------------------------------
+
+Didier noted that he's been approached by the DPL.  The DPL would like
+to produce a Debian Roadmap and believes the TC may have some role in
+that process.
+We started discussions of whether the TC might have a role, and
+limitations of a road map.
+There was agreement that we'd like to see a road map that facilitates
+work rather than a road map that discourages developers from working on
+things.  The project should be what the DDs as a whole want; if the roap
+map goes against that, it will be problematic.
+
+----------------------------------------
+
+Please send any comments/additions/corrections to the list.  I will
+propose that we approve these minutes at our next IRC meeting, as well
+as including an agenda slot for any additional discussion of topics from
+the breakfast meeting, particularly any concerns from those who were not
+there.