18:59:26 <OdyX> #startmeeting
18:59:26 <MeetBot> Meeting started Wed Aug 26 18:59:26 2015 UTC.  The chair is OdyX. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:35 <OdyX> #topic Who is here?
18:59:44 <OdyX> Didier Raboud
18:59:59 <OdyX> #chair dondelelcaro
18:59:59 <MeetBot> Current chairs: OdyX dondelelcaro
19:00:06 * aba 
19:00:31 <hartmans> Sam hartman
19:00:36 <dondelelcaro> Don ARmstrong
19:00:56 <KGB-3> 03Andreas Barth 05master 5429548 06debian-ctte 10636783_supermajority/intro proper title for GR proposal
19:00:59 <hartmans> My apologies for missing the bof.
19:01:06 <OdyX> Same for me.
19:01:10 <hartmans> I didn't track when it got rescheduled to.
19:02:05 <OdyX> bdale, Mithrandir, vorlon, keithp: around ?
19:02:34 <hartmans> I thought mithrandir gave regrets in IRC?
19:02:37 <keithp> yup
19:02:42 <OdyX> Let's wait 2-3 minutes more, I'm too swisso'clock.
19:02:52 <OdyX> ah yeah, no Mithrandir
19:04:09 <aba> while we wait I'd be happy to have review comments on 636783_supermajority/intro
19:04:20 <aba> (quite short text)
19:04:46 <bdale> I'm here, but multi-tasking (in a $dayjob call)
19:05:03 <OdyX> I'm not too convinced that merging all 3 issues is worth the try though
19:05:07 <OdyX> Anyway, let's start.
19:05:11 <OdyX> #topic Next Meeting?
19:05:28 <OdyX> dondelelcaro: where do we stand wrt next meeting ? I haven't followed up closely
19:05:43 <dondelelcaro> Currently, this should be in the same time slot on the 30th of september
19:05:44 <keithp> bdale: yeah, me too :-)
19:05:53 <aba> won't work for me
19:05:55 <dondelelcaro> I'll update the calendar with it shortly
19:06:05 <aba> could we move it, best by at least 2 days (in either direction)
19:06:08 <dondelelcaro> if anyone has a problem, please update the meeting vote script
19:06:08 <aba> +?
19:06:27 <OdyX> not 29 for me.
19:06:36 <dondelelcaro> aba: I'll update the dates in the meeting vote script; if people can tweak their selection, that would be awesome
19:06:45 <OdyX> #action everyone to update the script with its preferences.
19:07:00 * dondelelcaro is going to have to head out, but will try to catch up later
19:07:01 <aba> dondelelcaro: I try to find out how you did it afterwards, so I could do it next time myself
19:07:20 <dondelelcaro> aba: oh, you just manually change it; it's a shell script which calls pocket devotee
19:07:39 <OdyX> okay, let's iron the details through the repo.
19:08:14 <OdyX> (please shout if I'm going too quickly through the points)
19:08:17 <OdyX> #topic #741573 On menu systems
19:08:23 * dondelelcaro is going to have to step out; I'll check in later.
19:08:27 <aba> see you
19:08:30 <OdyX> ++
19:08:47 <aba> sune reviewed keithps proposal and considered it good (with a small change)
19:09:12 <OdyX> Status is we got several feedbacks from Charles & Sune, which I think is mostly in agreement with keithp's proposal.
19:09:17 <keithp> cool
19:09:36 <OdyX> keithp: your input on some points in the thread would be welcome though.
19:09:47 <hartmans> I still haven't seen an explanation of why Keith's proposal is better than option AB
19:09:57 <OdyX> recomforting Charles on where yours come from.
19:10:06 <hartmans> I really would like to see that as part of the ballot option.
19:10:07 <KGB-3> 03Andreas Barth 05master 8ae67d5 06debian-ctte 10meeting_poll/run_vote.sh hope to have updated my preferences for sep meeting correctly (wed won't work)
19:10:35 <OdyX> hartmans: for me, AB is a "pleases-them-all" solution, where keithp's is a better all-in-all  solution, IMHO
19:11:18 <OdyX> AB is the result of a complicated consensus and compromise process, but I think keithp's is a better technical solution
19:11:28 <hartmans> Why?
19:11:34 <keithp> hartmans: my proposal was a 'what I think the technical solution should be', while AB is a 'everyone agreed'
19:11:39 <OdyX> hartmans: for me, keithp's has the net benefit of clearly phasing menu out.
19:12:04 <hartmans> OK. but let's say that if we believe it.
19:12:11 <keithp> hartmans: my proposal was to deprecate the existing menu system, not make them equal. essentially suggest that applications *not* provide menu files
19:12:12 <OdyX> (it arguably puts the burden on "whoever cares about menu")
19:12:27 <hartmans> I think it is really disrespectful to do something other than the agreement result without  telling them why.
19:12:50 <keithp> OdyX: really, what I want it to read as is asking the existing menu system to be able to parse .desktop files instead of using a different format for similar info
19:12:59 <hartmans> And "this is better," seems incomplete to me.  We're mature enough technologists that we ought to be able to enumerate the properties of a proposal that make it better.
19:13:04 <aba> hartmans: disrespectful to whom?
19:13:20 <hartmans> If it is that Keith's proposal phases out the menu format  (or do you mean menu package), then let's actually say that.
19:13:45 <hartmans> aba: those who participated in the process in debian-policy.
19:13:47 <keithp> hartmans: agreed, any vote that includes my proposal should make the effect of that clear
19:13:57 <OdyX> keithp: yes. The principal source of metadata becomes the .desktop files.
19:14:12 <keithp> effectively deprecates the menu file format and pushes the menu packages to use .desktop file contents
19:14:37 <hartmans> aba: For myself I've found it really is frustrating and demotivating to spend your energy towards something and have some other body come along and decide something else.  That pain is much less when you can understand that your input was considered and understand why they choose differently.
19:14:54 <keithp> hartmans: just to be  clear, while I believe the proposal I wrote is a solid technical plan, I'm not at all opposed to a resolution that is softer than that and lets the project move in that direction more gradually
19:15:02 <OdyX> hartmans: it's better because we decide on having one single source of metadata, instead of two.
19:15:23 <hartmans> odyx: OK.  But please say that in the ballot option.
19:15:24 <keithp> OdyX: right, the question is whether to have the TC make that decision, or leave it up to the packagers
19:15:50 <hartmans> Also, I'd like to draw attention to Charles's latest comment.
19:15:53 <aba> hartmans: my understanding is also that e.g. Charles & Sune are participiants of the discussion, and if they like the outcome, I can't consider it unfriendly to them
19:16:14 <aba> (otherwise, yes, I understand your motivation)
19:16:15 <hartmans> He believes that Keith's proposal without a change to 9.6 to remove the recommendation that all command line utilities have a menu entry would be harmful.
19:16:18 <OdyX> frankly, I don't believe that "leaving it to the packagers" will work.
19:16:37 <hartmans> I think there's a lot to to that: I don't think we want desktop entries for command line stuff in the standard desktop menu.
19:17:31 <OdyX> hartmans: yes, I was arguing that these two changes are orthogonal, and the TC decision shouldn't be understood as writing the actual "whether a menu/desktop should be provided" into stone.
19:17:55 <hartmans> They clearly aren't orthogonal though.
19:18:00 <OdyX> hartmans: actually, I think this part of the Policy is a) not enforced; b) outdated.
19:18:09 <hartmans> I agree with you.
19:18:15 <aba> and therefore ... c) irrelevant
19:18:20 <OdyX> yes.
19:18:39 <aba> otherwise, the question if two questions are orthogonal already set another decision on fire
19:18:41 <hartmans> however, making the change away from  menu format to desktop without relaxing that requirement gives us a very different policy than we have today.
19:18:51 <OdyX> We could add to keithp's proposal a new point that voices the TC opinion in arguing that this should be changed.
19:19:21 <aba> OdyX: or "we consider this to be changed unless the delegates decide otherwise"?
19:19:22 <hartmans> You may believe that no one will actually do what policy says, but in general I'd prefer that we write a policy we'd be happy for people to follow.
19:19:23 <keithp> hartmans: that almost seems like a bigger change than moving metadata formats
19:19:32 <aba> hartmans: I agree with that
19:19:41 <aba> (re "You may believe ...")
19:20:01 <hartmans> keithp: It is.
19:20:12 <hartmans> But option AB effectively accomplishes that change, where as your proposal does not.
19:20:43 <hartmans> Because option AB doesn't apply the 9.6 language to the desktop format, only to the menu format, but relaxes the idea that we need menu entries.
19:20:48 <OdyX> aba: I'd write something like "we recommend that this should be changed"
19:20:56 <hartmans> But by combining formatis, you don't end up having that effect.
19:21:09 <aba> keithp: what do you think about that?
19:21:35 <keithp> aba: I think we've uncovered the kernel of the issue here, and that my proposal is almost a side issue
19:22:27 <OdyX> keithp: would you be up (and have bandwidth) to enhance your proposal on this basis ?
19:22:34 <keithp> and, I agree that package developers should make reasoned decisions about what to add to the desktop selection of applications
19:23:13 <keithp> OdyX: it seems like a simple change, but I'm wondering now if we shouldn't resolve these issues separately
19:23:16 <aba> if this is related enough that we care, we can we not fix it at the same moment?
19:23:35 <aba> (perhaps also in two decisions?)
19:23:36 <hartmans> So, I'd like to see this move forward soon.  I think I could support a version's Keith's proposal that 1) explained the reason we prefer it is that we want one metadata format; 2) relaxed or recommended relaxing 9.6
19:23:50 <OdyX> hartmans: one decision, or two decisions ?
19:23:52 <hartmans> I'd be happy to help contribute text to such a ballot option if it would get us moving forward.
19:24:43 <hartmans> I need to vote on them as one decision because I'd rank the options that change metadata format to .desktop but do not relax 9.6 much lower than others.
19:25:09 <OdyX> Action: keithp & hartmans to work on this ?
19:25:22 <hartmans> Actually, I could vote on 9.6 before the desktop becomes the format decision.
19:25:48 <hartmans> Keith, would my help be useful/welcome?
19:25:52 <OdyX> ah, that's an interesting idea.
19:25:59 <keithp> OdyX: agreed. I can update my proposal to add the wording I had suggested about deciding when to make menu system entries based on expected usage patterns
19:26:56 <OdyX> #action: keithp & hartmans to iron out a proposal also deciding upon §9.6's relevance
19:26:59 <aba> sounds like we finally have progress.
19:27:02 <aba> good, thanks.
19:27:16 <OdyX> Yeah, Good to see this moving.
19:27:17 <keithp> hartmans: let's do this today via email if we can
19:27:29 <hartmans> Where is the current version of Keith's proposal/b allot option D
19:28:00 <OdyX> 741573_menu_systems/odyx_draft.txt afaik
19:28:09 <hartmans> ok, tnx
19:28:16 <OdyX> #topic #771070 Coordinate plan and requirements for cross toolchain packages in Debian
19:28:33 <hartmans> any progress at debconf?
19:28:34 <OdyX> For info, vorlon attended the relevant part of the multiarch BoF, but isn't available right now.
19:28:49 <aba> hartmans: AFAIUI yes, but I hoped for a more detailed report now
19:29:21 <OdyX> same. Didn't have the courage to attend myself :/
19:29:26 <aba> (or not so probably at next meeting or by mail)
19:29:32 <OdyX> Anyway, I think we need vorlon's feedback.
19:29:40 <hartmans> ok
19:29:57 <OdyX> #action vorlon to report on his presence during the DebConf BoF
19:30:11 <OdyX> #topic Constitutional change proposals
19:30:19 <OdyX> #save
19:30:23 <aba> we discussed about that at debconf, and considered it easier to propose it via normal process (in order to be able to accept amendments)
19:30:27 <hartmans> aba: I read your intro and it seems reasonable.
19:30:36 <aba> also I volunteered to do that
19:30:47 <OdyX> I'm only not convinced that merging the 3 is the most efficient.
19:30:48 <aba> (and we only pick the easier ones for now)
19:31:06 <aba> OdyX: which ones should be part of the first GR?
19:31:07 <hartmans> I think it will become obvious if merging is bad and we can unmerge at that point.
19:31:09 <OdyX> That would be supermajority + numbering + discussion ?
19:31:14 <aba> hartmans: sure.
19:31:18 <aba> right
19:31:34 <OdyX> supermajority + numbering, totally in favour of merging
19:31:39 <aba> but I'm happy for any other combination if there is one which should be postponed, or be put into the first GR
19:31:46 <OdyX> private-discussion might be picky
19:31:59 <aba> in that case, I'd remove that one from the GR
19:32:19 <OdyX> but I think we can try a common proposal, and split from then on in case of friction.
19:32:53 <OdyX> okay, let's move on with this.
19:33:04 <aba> ok.
19:33:11 <OdyX> #action aba to proceed with combined GR with supermajority + numbering + private-discussion
19:33:35 <aba> I'll send out the proposal now then, so please sponsor it soon then
19:33:41 <OdyX> #topic #636783 Constitution: super-majority bug
19:33:47 <OdyX> #topic #795854 Constitutional Amendment: Fix duplicate section numbering (A1)
19:33:52 <OdyX> #topic #795859 Permit TC to hold private conversations
19:34:06 <OdyX> Any comments on these three ?
19:34:25 <hartmans> I don't know how I feel about private discussion GR.
19:34:50 <hartmans> But it's not like we can't talk privately as individuals, so it's probably harmless
19:35:03 <aba> I personally won't consider this one necessary but well
19:35:45 <OdyX> do we need to decide this as TC, or can we iron this within the GR discussion ?
19:35:58 <aba> I'd like to ask a question:
19:36:07 <aba> anyone here who considers this change to be necessary?
19:36:23 <aba> (I think Ian wasn't happy without the change)
19:36:34 <aba> bdale: do you have any take about that specific change?
19:36:45 <keithp> aba: the private conversation one?
19:36:48 <aba> yes
19:37:08 <aba> OdyX: if no one needs it I prefer to iron it out prior to the GR discussion :)
19:37:12 <keithp> that was to address the need to talk to participants in an issue as the full ctte without needing those to be public
19:38:10 <keithp> we can work without that, but there have been a few times where private conversations might have allowed for different communication contents, which may have made things easier overall.
19:38:29 <OdyX> Hrm. I just re-read it, and it actually reads as a bigger constraint that without it.
19:38:34 <keithp> especially where emotions are driving behavioru
19:38:37 <aba> I don't think the constitution requires us to have all discussions public except formal resolutions but well.
19:39:05 <keithp> aba: conventionally, we have done everything in public
19:39:24 <aba> keithp: at least most, yes.
19:39:37 <OdyX> I think the title and the amendment contradict eachother
19:39:59 <aba> OdyX: yes, it should rather be "regulate the usage of private discussion"
19:40:05 <aba> because that's what it's doing
19:40:20 <OdyX> the amendment rather insists on limiting the use of private discussion
19:40:36 <aba> of course if you limit that, it means that it is allowed.
19:40:43 <aba> otherwise you don't need to limit it.
19:40:46 <OdyX> yeah, right.
19:40:48 <keithp> OdyX: the constitution does say that all discussions are to be public, except for appointments
19:40:55 <aba> or "limit private discussion"
19:41:35 <OdyX> keithp: right.
19:41:44 <OdyX> I don't quite like the phrasing of the amendment.
19:42:00 <aba> I'd say: this one isn't ready yet.
19:42:17 <aba> so I think I'll remove it from the current proposal, and we need to fine-tune it.
19:42:45 <OdyX> #action aba to proceed with combined GR with supermajority + numbering
19:42:53 <OdyX> then ?
19:43:28 <aba> #action aba to address different proposal for private discussions
19:43:39 <OdyX> Cool, let's move on.
19:44:03 <OdyX> #topic #795855 Formal cloture vote
19:44:28 <aba> one question on the above:
19:44:29 <hartmans> I'd like to find some other way to approach this.
19:44:42 <hartmans> I understand the issue, and agree with vorlon that we need to do something here,
19:44:45 <OdyX> While I sympathize with vorlon's concerns, this really feels like it will be limiting.
19:44:49 <hartmans> but Ian's proposal is very heavy-handed.
19:44:50 <aba> should I put in "there might be more issues coming up but these two are ready so we#d like to get them fixed now"?
19:45:45 <aba> I had a discussion with bdale during IIRC lunch about this
19:47:06 <OdyX> well, is there any action point we can hand out ? :)
19:47:07 <bdale> sorry, I was 100% consumed my my work call, and now must go afk to get ready for a departing flight this afternoon.  sorry I wasn't able to be more engaged, feel free to poke me in email for anything my personal input would be good on
19:47:08 <aba> the outcome was rather like "we should have any option on that at least $num ctte members want to have as first priority" (whereas first priority means each of us could only force one option on)
19:47:17 <aba> OdyX: sorry, typing too slow
19:48:10 <hartmans> Why is it bad to have a whole bunch of options on the ballot if people really need them?
19:48:20 <KGB-3> 03Andreas Barth 05master 010af67 06debian-ctte 10636783_supermajority/intro don't include the private discussions text into the first GR
19:48:23 <hartmans> I realize it's a bit annoying, but what would break with a 20 option ballot?
19:48:32 <OdyX> well, I really feel the situation from which these proposals came out was really special, and shouldn't be used as a generic argument for a failure of the constitution
19:48:42 <aba> hartmans: technically condorcet might have an issue
19:48:53 <hartmans> aba: in what way?
19:49:27 <aba> OdyX: I think the constitution should basically say "in normal cases, we do it this way. If we are ever in such a special case again, these rules apply"
19:49:27 <OdyX> hartmans: condorcet fails to be really relevant when n_options > n_participants.
19:49:53 <hartmans> In what way?
19:50:07 <aba> (and "this way" is we add as many options as people like, and can call for votes without any lead time but wait until everyone is ready)
19:50:41 <OdyX> hartmans: tactical voting, etc.
19:51:01 <hartmans> I'm sorry, I don't understand.
19:51:43 <hartmans> I've seen a number of things described as tactical that in practice seem to be people expressing their honest preferences.
19:51:57 <aba> hartmans: that too. Like for that special situation
19:52:00 <hartmans> Especially with ranking things above and below FD.
19:52:19 <bdale> my personal take is that condorcet is quite good at picking 1 of N choices on a single conceptual axis, but with a small voting population trying to answer 2 or more questions with a single ballot becomes wickedly confusing
19:52:24 <keithp> hartmans: the appearance of tactical voting is a problem, and FD makes it possible
19:53:11 <OdyX> hartmans: concretely, the convolution of orthogonal issues in the controversial systemd ballot would have made the result unreadable.
19:53:40 <hartmans> odyx: We're not in agreement on that.
19:53:52 <OdyX> hartmans: I know :)
19:54:05 <hartmans> I've had experience with large ballots on IETF nomcom where we voted for entire slates.
19:54:21 <bdale> the worst of the anxiety in the initsystem debate was I think very much mired in our internal disagreement about this issue
19:54:26 <OdyX> I think we should really thrive to solve one issue per ballot, and not add administrativia overhead to avoid this.
19:54:27 <hartmans> It took a while to get used to, but it seemed in that instance to work quite well, certainly better than any of the other alternatives.
19:55:20 <aba> I think I'll propose a different solution to this one based on the discussions I had at debconf
19:55:21 <OdyX> hartmans: concretely, weak vs strong coupling wasn't really a question that was asked to the TC, and there were several TC members not happy with having to decide this.
19:55:22 <hartmans> I don't want to rat hole here, but I'm going to need significantly more than one sentence explanations to see the problem here.  I will try to do my part to understand, but what I'm hearing sounds a lot like "trust us," and I have tried to think about this a fair bit and seem to be coming up with different conclusions.
19:55:31 <hartmans> But this meeting is probably not the place to resolve that.
19:55:34 <bdale> bottom line to me is that I'm not sure we really want or need a constitutional change here, because this is something that only came up once, and we all hated being in that position and don't want to do it again.  but since my tenure on the board ends soon, I certainly won't stand in the way of others who think differently
19:56:08 <hartmans> odyx: Yes, but there were some TC members who did want to link the issues.
19:56:11 <aba> bdale: I tend to have it on the constitution as an exceptional rule, i.e. in normal times it doesn't prevent us to act as alwass
19:56:24 <hartmans> You could have had a ballot with the four unlinked options and the linked options that seemed plausible.
19:56:33 <hartmans> (I.E. no one was going to vote for tight openrc)
19:57:02 <OdyX> hartmans: that's what I'm naming "tactical"
19:57:31 <hartmans> That's not tactical: that's an honest difference of technical opinion.
19:57:40 * aba agrees with hartmans on this
19:57:43 <OdyX> hartmans: forcing a decision on coupling was (from a back-then outsider point of view) a way to make sure upstart would win.
19:57:45 <bdale> I have to walk away now, for real, so I can't continue the discussion here and now... but hartmans, I'll be happy to chat with you about this some other time.  I may in fact just be wrong, but based on what we went through for the initsystem debate, I have fairly strongly held opinions here
19:57:56 <hartmans> O, forcing the decision was tactical.
19:58:19 <hartmans> But it would not be tactical to have both linked and unlinked options on the ballot.
19:58:25 <aba> OdyX: I disagree with that statement as well btw
19:58:33 <bdale> I don't find the word "tactical" useful here, fwiw
19:58:34 <hartmans> But it is tactical to manipulate the process to either get a purely linked or purely unlinked ballot.
19:58:44 <OdyX> yeah, right, sorry for the choice of words.
19:59:00 <aba> could we move on?
19:59:09 <OdyX> Yes.
19:59:19 <OdyX> I'm not going to push this, as I prefer status quo.
19:59:37 <aba> so, I'd like to add another proposal that doesn't add bureacracy to the normal case
19:59:39 <hartmans> I'm happy to move on
19:59:46 <aba> however with low priority as other things are more urgent
19:59:48 <aba> ok?
20:00:05 <OdyX> yeah, more options can't hurt.
20:00:13 <OdyX> #topic #795857 TC chair appointment
20:00:49 <OdyX> On this front, I quite like bdale's proposal.
20:01:03 * aba too
20:01:18 <OdyX> it needs someone to produce a constitutional diff
20:01:36 <aba> I'll do
20:01:39 <aba> one question:
20:02:17 <aba> I think the vote should start $time after the change in composition becomes effective, and also be coupled on the calendar
20:02:46 <aba> reason for the second: then we don't need to stare at "when did the mail from the dpl appear"
20:03:26 <aba> e.g. "it starts on the next 10th or 24th of the month after the change become effective" (ok, text should be written while I'm more awake)
20:03:33 <aba> what do you think?
20:03:38 <OdyX> again, I wouldn't add timing constraints, just something simple that says "a new TC chair appointment must happen after every TC composition change"
20:03:39 <aba> or should we discuss that by mail?
20:03:51 <aba> OdyX: ok, and any tc member could call on votes?
20:04:11 <aba> (which would also de-couple from the exact dates which is relevant to me)
20:04:30 <OdyX> aba: timing constraints are going to hurt, one time or another
20:04:49 <aba> sure, I think your proposal is better
20:05:00 <OdyX> add a "before the TC can take decisions" if that really need to be enforced
20:05:22 <OdyX> #Move this to list ?
20:06:01 <aba> so some text like "Anytime the composition changes there should be a vote on the chair, any TC member can call for votes on that. If a call for votes on the chair is called, for any other not yet decided resolution the new chair has the cast vote"
20:06:06 <aba> but yes
20:06:12 <OdyX> #action aba to draft a constitutional diff imposing a TC chair appointment after every TC composition change"
20:06:23 <OdyX> #topic Additional Business
20:06:51 <aba> I heared we have something else coming up
20:06:56 <OdyX> ah
20:07:18 <OdyX> public enough ?
20:07:27 <aba> someone told me that systemd/packagekit does automatic system updates, and maintainers considers it a feature
20:07:40 <aba> otherwise I think we should wait till the bug arrives at us
20:07:45 <OdyX> there was a chat on this on debian-devel.
20:08:01 <OdyX> Last I understood, this was still under heavy discussion.
20:08:01 <hartmans> *why* o*why* is systemd part of that.
20:08:07 <hartmans> :-)
20:08:12 <aba> well, I had "as tc member you should know about because ..."
20:08:15 <aba> we'll see
20:08:31 <aba> another thing, we had the ask the ctte bof at debconf
20:08:38 <aba> which I think was fairly good (again)
20:09:39 <hartmans> anything come up there that should be brought to a brooader audience?
20:09:40 <OdyX> yes. Sorry for having missed the rescheduling
20:10:09 <KGB-3> 03Andreas Barth 05master 955ff7d 06debian-ctte 10636783_supermajority/intro wording fix
20:10:40 <aba> hartmans: not really
20:10:53 <hartmans> tnx
20:10:56 <aba> I think it was quite interessting for those asking us
20:11:04 <aba> to get an better understanding how the ctte works
20:11:11 <aba> well, hm. there is something.
20:11:29 <aba> we also told people that we have the change to re-allocate two seats soon
20:11:39 <aba> so this is something we also should start to work on here
20:12:33 <OdyX> ah yeah, right. We should have a private repo for candidates and their statuses?
20:12:34 <aba> i.e. I think we should do an call for volunteers sooner than later (however I think it would be good if Don would do it)
20:12:53 <aba> I didn't think we ever had. We just had a status mail IIRC
20:12:59 <OdyX> okay, works too.
20:13:13 <aba> I think we should put in the minutes that we need to work on it
20:13:24 <aba> and anyone who would like to could create a draft for d-d-a
20:13:32 <OdyX> #info We should really start working on the two seats renewals.
20:13:44 <OdyX> I'll try to see if I can draft something.
20:13:51 <OdyX> #action OdyX to take a look
20:13:55 <OdyX> Anthing else ?
20:13:56 <aba> constitution doesn't force us to have more than six people but I think it would be good
20:14:04 <OdyX> Yes.
20:14:06 <aba> and I just sent the GR proposal out
20:14:22 <OdyX> Cool, thanks
20:14:26 <OdyX> #save
20:14:35 <aba> otherwise for me I think we're done
20:14:44 <OdyX> Great. Thanks for the lively discussion.
20:14:56 <OdyX> #endmeeting