21:00:22 #startmeeting crossproject 21:00:23 Meeting started Tue Dec 1 21:00:22 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:27 The meeting name has been set to 'crossproject' 21:01:13 hi 21:01:14 o/ 21:01:17 here 21:01:23 o/ 21:02:02 o/ 21:02:03 courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle 21:02:06 courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker 21:02:08 courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik 21:02:10 courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT 21:02:12 courtesy ping for vipul annegentle SergeyLukjanov devananda boris-42 nikhil_k and lifeless 21:02:14 sorry for the old ping list, will update it later 21:02:16 o/ 21:02:25 dhellmann: ping 21:02:35 o/ 21:02:57 agenda for today 21:03:14 #topic Team announcements (horizontal, vertical, diagonal) 21:03:20 https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 21:03:37 o/ 21:03:42 \o 21:03:50 /\ 21:04:42 remember that this week is the mitaka-1 milestone deadline (3 Dec) 21:05:00 see the email thread on the ML for details about how we'll be doing tags this time 21:05:03 its been a while since we've had a meeting, since we have them when an agenda item is actually called for. I hope most people felt necessary cross-project announcements and other important bits have been making it on the dev list digest that's produced each week 21:05:03 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080692.html 21:05:05 http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151121/ 21:05:17 ++ 21:05:33 thingee: +1 21:05:52 #info this week is the mitaka-1 milestone deadline (3 Dec) 21:06:26 anything else? 21:06:45 #topic backwards compat of libraries and clients 21:06:48 lifeless: hi 21:06:50 o/ 21:07:07 all in favour say aye? 21:07:15 (doesn't think there is much other option) 21:07:19 https://review.openstack.org/#/c/226157/ 21:07:24 #link https://review.openstack.org/226157 21:07:37 I think we're trying to do this in keystone already 21:07:46 lifeless: so I think armando raised a good question. what are the first steps for ptls to help out? 21:08:02 so 21:08:10 the biggest thing has been getting consensus 21:08:29 ++ for consensus 21:08:37 I've had immense concerns raised that 'developers won't do this' - though every actual developer has been ok once they walk through the logic 21:08:59 the actual mechanical bits of re-enabling our old jobs and tweaking them is almost entirely project-config changes 21:09:02 if you add tests the developers won't have a choice 21:09:13 bknudson: they can unionise 21:09:20 hunger games ftw 21:09:21 lol 21:09:23 lol 21:09:26 I'm feeling the bern already 21:09:42 so - I think we have broad buy in 21:09:44 fungi, dims, sdague johnthetubaguy ping 21:09:46 o/ 21:09:48 even harlowja is on baord 21:09:53 i converted 21:09:55 o/ 21:09:56 heyhey 21:10:03 so I think the next steps are: 21:10:04 lifeless, Yeah, right. The only engineers that have ever unionized in the US worked for Macdonald Douglas and it was *really* bad there 21:10:11 I think there are exceptions to most things and there are likely to be some here 21:10:16 - some fine tuning based on the nits in the reviews 21:10:38 - some opt-out mechanism for new-style incubated libraries and immature clients 21:11:05 - profit 21:11:09 only say this because there is a group that wants to refactor some (not to be named) library 21:11:17 then tc approval, and after that its going to be a matter of adding the jobs non-voting, make sure they pass, then make them voting 21:11:21 lifeless: I'm not seeing pushback, but not enough eyes for complete consensus is what you're wanting? 21:11:25 individual projects can obviously race ahead on that if they want 21:11:39 thingee: I don't know what the threshold needs to be 21:11:50 thingee: we're a couple of months into 'get eyes on it now' 21:11:51 we've never really formalized that. 21:11:54 is there going to be a new job on python-keystoneclient ? 21:12:06 thingee: I think at a certain point we go 'folk gotta deal' or something 21:12:14 bknudson: yes 21:12:37 good... I just didn't want it to be an unrelated job that failed. 21:12:44 (like we have now) 21:12:45 bknudson: so to use that as an example, we'd make sure that all the supported servers work with changes to keystone master 21:12:52 I say, push to TC, this will be the last week for projects to raise show stoppers. 21:12:57 bknudson: and that keystone master works as a client to all the servers 21:13:08 bknudson: and similarly for keystones liberty branch going backwards only 21:13:42 the people that are upset that they didn't catch this will only support the next agenda item/my proposal for cross-project liaisons :) 21:13:54 thingee: so, I'm your fulcrum huh? ok :) 21:14:00 thingee : this will have the biggest impact on oslo developers, so I would like to get them to +1 the spec 21:14:21 dhellmann: cores, or all 21:14:35 lifeless : cores should be enough, but more wouldn't hurt 21:14:43 so, we can round up cores easily enough 21:14:53 but if folk don't respond to a direct email to come comment, I don't want to block 21:15:02 * harlowja it'd be interesting imho to see what mike bayer thinks (due to his wealth of experience around sqlalchemy) 21:15:11 good idea 21:15:17 dhellmann: what's the best way to wrangle cores in oslo? A post to the ML tagged with [oslo]? :) 21:15:20 lifeless : I do. This is making new rules they did not agree to when they signed up to do the work they're doing. 21:15:37 thingee : that and talk to dims. There aren't that many cores, it shouldn't take long. 21:16:19 thingee : dhellmann : +1 21:16:22 dhellmann: and if one just doesn't answer at all? How long do we wait? 21:16:24 lifeless can u possibly directly poke mike (not like in person) 21:16:28 lifeless : I don't expect a lot of resistance, based on what you've said about talking to other folks, but this is a big change in the way they're used to working now. 21:16:31 *unless u want to poke him in person 21:16:33 dhellmann: I'm not suggesting being callous or railroading 21:16:36 dims: do you need anything from me to wrangle, or can you? 21:16:46 dhellmann: but the reality is that people change focus and don't always tell us they've done that etc 21:16:53 dhellmann : in principle it's all good. just not sure how it will work out practically 21:16:58 harlowja: I'll ping him zzzeeek right ? 21:17:02 lifeless righto 21:17:03 lifeless : can we give it until next week? dims should have a good sense for who is active these days 21:17:12 dhellmann: sure 21:17:13 yes please 21:17:19 dhellmann: that's fine with me. 21:17:32 will ping one time in next oslo meeting and then we can wrap it up 21:17:40 (on monday) 21:17:58 #action dims will notifying oslo cores on the spec to raise any issues 21:18:06 lifeless : jd__, haypo, gcb, bknudson, maybe a couple more are really active this cycle 21:18:07 thanks thingee 21:18:23 I'll go through the nitty comments and issue an updated spec soon as well 21:19:07 dhellmann u forgot me, hahaha 21:19:13 sounds like we have a plan 21:19:23 thanks lifeless for your patience 21:19:25 harlowja : he had already mentioned you :-) 21:19:28 oh 21:19:44 i'll learn to read someday 21:19:45 oh, wait, no, sorry, I thought he was listing you and zzzeek together there 21:19:48 lol 21:19:53 np :-P 21:20:02 #topic cross-project liaisons 21:20:43 ttx raised to me the slow progress forward with lifeless' spec. This is due to lack of attention some cross-project specs get. 21:21:13 not enough eyes to feel good on consensus. For example, dhellmann raised oslo core should be included with reviewing this spec. 21:21:22 that would've been missed and gone to tc approval 21:21:30 * rockyg thinks lack of attention is for *most* cross-project specs 21:22:05 to avoid this I have proposed the idea of having representatives in each project to be observant of cross-project initiatives http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html 21:22:09 #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html 21:22:59 cross project specs are slow, impossible! ha 21:23:18 the problem is PTL's are usually too busy for these things. It would be great if someone from each team was aware of things and was able to act on the spec representing their project, or bring in the necessary knowledgable people for the spec. 21:23:38 does someone have a link to diff between oslo and cross project specs? 21:23:39 and also make their own projects aware in their own individual meetings. 21:23:53 could we more clearly define what a PTL does, and include cross-project-stuff in that listing 21:23:59 ? 21:24:15 thingee: i thought it sounded like a good idea, i'm curious, process-wise, about how the increased participation will occur 21:24:17 (browsing reddit would not be in that list) 21:24:25 for other liaisons we defaulted to the ptl 21:24:33 it seems like we'll need people will good awareness of their projects to really help out 21:24:42 the ptl does everything, or delegates (sometimes passively) what is not done directly 21:24:57 How about cc'ing all cross-project liaisons automagically to all cross-project spec reviews? 21:25:10 One thing I think would help is to push adding openstack-specs to your PTL watch list: https://review.openstack.org/#/settings/projects 21:25:20 s/PTL/project/ 21:25:29 based on the feedback at the summit in the cross project communication session, I have received from current/previous ptls that they were too busy for this. I would still like someone to bring interesting things up to their projects when needed. 21:25:39 :( def 21:25:55 Anyone tought about the idea that the issue is cross project specs and the fact that they need to please constantly growing amount of teams and people just get tired of munching the same thing week after week (on both proposing and reviewing sides)? 21:25:57 PTLs can delegate 21:25:57 to busy to think about cross-project stuff scares me (alot) 21:26:03 ++ 21:26:13 yeah I was going to say the same thing 21:26:16 yeah, i didn't mean to imply that ptls do have time to be -liaisons, just that they need to delegate others who can if they cannot 21:26:44 seems essential a PTL should be able to shave a tiny bit of time off to just watch for cross-project impact on the ML, surface in a weekly meeting, and scare up a delegate? 21:27:02 I would love the idea if we could cc PTL's to a spec, and nag freely to delegate. 21:27:13 if no response comes from a necessary project in a spec 21:27:25 jokke_: so, we should have less projects? 21:27:31 jokke_: or less consistency across projects? 21:27:50 jokke_: or less ownership within projects (e.g. let other folk change the rules [for good reasons] without consultation? 21:28:04 many (most?) reviewers ignore gerrit subscriptions and are using dashboards or other filter mechanisms to spot reviews which require their attention 21:28:05 I think it makes sense to have cross project liaisons 21:28:14 jokke_: or perhaps lots of cross-cutting teams that own the thing (e.g. a team thats owns code hygiene like being lint-clean) 21:28:33 having less/thinner feedback usually means that some projects find issues later 21:28:59 I don't think the issue is with more people, it's more about what to watch out in the spec is important 21:29:05 you can still have fly by -1s 21:29:06 lifeless: in a perfect world none of the above wouldn't be needed, but in real world some of the things you mentioned might be the right way to go to get something actually done 21:29:30 so I think the cross-project liaison idea is flexible. If the PTL wants to be the one to delegate here, they can be. But they must dedicate some time to the duties I listed in the ML post. Otherwise, they can delegate now to someone to keep up with specs, or delegate to someone who is knowledge in the area of the spec that can represent their project. 21:29:35 nikhil: +1, i like the idea of dedicated cross-project liaisons 21:29:41 having designated repr matter and given a mic/responsibility for review their feedback would be honest and not a blocker 21:29:49 lifeless: no, maybe, maybe, yes :) 21:29:50 thingee: +1 21:30:07 we have an issue right now with pylint and how projects roll forward on that 21:30:17 we really could use a better way to figure out what to review. we've dashboards and next-review 21:30:19 its at least partly tied into whether or not we can move all of openstack lock-step 21:30:26 which is a cross-project thing 21:30:35 thingee +1 nothing isn't a solution (and completly avoiding cross-project stuff imho is not acceptable) 21:30:49 [pylint 1.5 broke compat with 1.4.4 - in some trees its not possible to have a single tree that passes both] 21:31:02 lifeless: the problem is that each project, engineer and company has their own priorities and interests ... it just might not make sense to spend any effort for cross project thing x if you have 20 more important matters in your pipeline 21:31:09 (and worse, astroid, a library it uses, broke compat in a point release. argh.) 21:31:24 jokke_: I think opting out is fine :) 21:31:35 and it just might mean that a) you don't get their imput b) you don't get their cycles even if someone else is doing it for them 21:31:35 jokke_: just say 'I am fine with what you choose and will follow the herd' 21:31:59 jokke_: whats not fine is 'oh no you made a bad choice after I had opportunity but failed to give input' 21:32:06 jokke_: at least for this, we're just wanting to agree on idea(s). It's a whole the group (product working group) to bring consistency on some of these specs. 21:32:16 whole other group* 21:32:28 So, sounds like we need an obvious 0 vote, or abstain 21:32:32 (imho its the whole community that needs to bring consistency on these specs, no single group) 21:33:49 I see enough problems having a single smallish team agreeing on something :( 21:33:55 harlowja, ++ 21:34:04 jokke_ life is hard 21:34:15 i had to get up this morning, it was cold... that was tough 21:34:22 it really means what sort of democratic model we plan to choose 21:34:32 jokke_: currently there is no team in cross-project. it's whoever feels like showing up 21:34:41 direct voting or delegated and both have trade offs 21:34:43 jokke_: that's the problem I'm trying to address right now. 21:35:13 thingee u will solve all the things! 21:35:19 i belive 21:35:28 there are also already plenty of smallish teams deciding things which impact all projects in openstack (qa, infra, docs, et cetera) 21:35:49 forgot api :P 21:35:51 harlowja: my point is you'll find always someone who does not agree or wants to bikeshed ... perhaps overruning those are not always worst choice but revisiting topic if it turned out to be such should not be problem either just because it was managed once to slam down 21:36:02 nikhil: that only impacts projects with an api ;) 21:36:15 fungi: true that 21:36:41 jokke_ agreed, there will always be those people, and there will always be choices which can be changed due to future knowledge (software moves to quickly to be so static) 21:37:04 jokke_: I think in previous specs that we've pushed successfully to TC for approval and looked past bikeshedding. I don't think this defined team introduces that problem. 21:38:24 but getting input on these specs is hard because there doesn't seem to be any urgency/timeline for them 21:38:25 thingee: do you have any numbers a) how long it took from first proposal to merge b) how many of them has been revisited after initial merge and c) digestion rate in the projects? 21:38:26 jokke_ : the solution to getting more agreement is to ensure folks are paying attention early, not to make decisions and try to convince them after the fact. we've seen that fail many times over the past few years. thingee's approach reuses the liaison system we've had good luck with for other cross-cutting teams, and I think it's a good idea. 21:38:49 thingee: I think those 3 things tells quite a lot how successful that process is 21:39:08 Maybe cp meeting specifically to thrash out a spec that looks like it will be adopted in some format? Two meetings, one for each side of the world? 21:39:22 I think question c is a bit unrelated. 21:39:25 jokke_: ^ 21:39:45 projects following through on specs is not what I'm solving in this proposal 21:40:03 although it wouldn't surprise me if this helps with projects being more aware. 21:40:09 I'm not against dedicated crossproject liaisons .... I think there is even list of projects having them already on the liaison wiki page ... I'm more worried if that will solve issue or just make it look prettier 21:40:22 * harlowja it would be interesting to know that rate in general, if it could be determined somehow.. 21:40:25 ideally we would keep the TC out of the process and just used as escalation 21:40:36 jokke_: the wiki doesn't have this idea today. I actually thought it was already defined and then was surprised when it wasn't :) 21:40:48 thingee: what's the point having those specs if their digestion to the projects is low? 21:41:49 jokke_: there is not much point. I agree today it's a problem, but I just got back from my wedding and honeymoon and decided to help fix this first problem of people not looking at specs to begin with. 21:41:52 :) 21:42:10 was there a spec for the wedding and honeymoon? 21:42:12 <3 :) 21:42:22 lol, btw grats thingee 21:42:50 And that's why specific meetings. Reviews get comments during meetings. That's how they attract eyes. 21:43:02 jokke_ on your point, u have to start somewhere, imho not trying isn't really an option, so here we are, all trying 21:43:03 harlowja: thank goodness no. my wife would have a fit if others had to bikeshed on the color of the tablecloths 21:43:05 when you say "the wiki" you're referring to https://wiki.openstack.org/wiki/CrossProjectLiaisons presumably 21:43:13 Maybe have the reviews brought up in each of the project weekly meetings? 21:43:29 considering the broad scope of openstack-specs, who exactly is implementing them? are there 10 names attached to each spec (because i'm assuming that's how many people are required to apply it globally) 21:43:33 fungi: yes 21:43:44 fungi: correct ... even the title points towards the topic :P 21:44:03 just confirming. didn't see anyone else mention the url 21:44:09 gordc depends on the spec, > 10 imho on major ones 21:44:21 but gordc its a valid question related to how these are 'digested' 21:44:35 There's no harm in trying a new process, we are all up for trying new processes these days anyways. 21:44:44 that's an interesting word 21:44:48 lol 21:44:57 I am not sure if things are digested completely 21:45:01 :P 21:45:04 don't ask what happens after digestion 21:45:15 nikhil: yup, we did it with this meeting for example :) 21:45:28 thingee: aye 21:45:28 I've been enjoying the participation in today's meeting too :) 21:45:40 word of the day 'digestion' 21:45:54 harlowja: the normal stuff ... outcome gets released ;) 21:46:07 harlowja: what can happen if not fully digested is the question :P (I think) 21:46:18 u visit the doctor? 21:46:28 nikhil, bikeshedding 21:46:37 sorry 21:46:42 so in terms of projects that need to be included... 21:46:58 No, no, that's what happens when not fully digested nikhil 21:47:19 tbh, i think openstack-specs is nice and fine. but i think like all broad-scoped ideas, there's is a lot of politiking you need to do. 21:47:19 thingee: everyone under the big tent! 21:47:30 that's what I was afraid of. 21:47:34 * gordc not trying to justify lack of presence on openstack-specs 21:47:37 I meant to raise there are a few things that are partially adopted in projects and sometimes it takes long, sometimes conflicts, sometimes livelocks. may be we come to full cycle back to original state ? someday? 21:47:40 So can we agree to go on a spec-by-spec basis? 21:47:56 rockyg: gotcha, ha! 21:48:06 some specs may only involve three identified projects while others can include 10? 21:48:13 gordc agreed, politiking helps the sugar go down 21:48:14 thingee: I thought you meant the liaisons 21:48:39 jokke_: I suppose it wouldn't be difficult to have something cc all liaisons. 21:48:41 * harlowja runs for food, bbl 21:49:05 harlowja: i'm assuming openstack-specs was suppose to avoid the politics... but i'm not sure there's a way around it 21:49:15 thingee, Yeah. All liaisons should get notice. 21:49:18 aside from people hopefully be diligent on watching the repo in their respected dashboard 21:49:21 thingee: mailing list should be for that ... it's so easy to follow already 21:49:21 +1 for cc'ing liaisons 21:49:33 there is no avoiding politics in any sufficiently large group of humans interacting 21:49:47 fungi: ie a group of 3? 21:49:48 amen, fungi 21:49:49 fungi: +1 21:49:50 and how about consensus? are those on spec-by-spec basis? 21:49:51 i still don't know what cc means in this context. e-mail? 21:50:03 fungi: easily ... only thing you need is strong dictator 21:50:09 notmyname, sometimes a group of 2 21:50:20 I think part of our problem is we don't really know when to merge openstack-specs 21:50:26 fungi: ++ (politi--something) 21:50:36 there can be a lot of +1's on something and it can still sit 21:50:44 fungi: i took cc to mean adding them to the reviews 21:50:59 thingee: doesn't tc own openstack-specs? 21:50:59 fungi: gerrit 21:51:00 thingee: yes! great question 21:51:13 thingee, that's why you post to ML, cc liaisons and have a meeting for final comments 21:51:26 should we put timeout to specs ... merge or abandon 6 weeks 21:51:37 elmiko: as i said earlier, adding people to reviews does little good, especially for most of our high-volume reviewers 21:51:38 what that the motivation behind ad-hoc meetings? 21:51:49 things seem to surface now 21:52:03 meeting to decide whether spec is ready for merge 21:52:04 nikhil: yes and rockyg's idea sounds good. but when do we feel confident to call that meeting? 21:52:05 s/what/was/ 21:52:05 fungi: fair, i don't think it should be the only step taken, but it's a step 21:52:23 people constantly add me to every review of theirs because i'm a core reviewer, a ptl, in the vmt, on the foundation staff, pick your reason. i have to ignore that feature of gerrit because for me it's noise 21:52:34 thingee: you ask your wife ofc 21:52:40 friday evening pacific time (jk). 21:52:54 thingee: they know always best 21:53:08 I also ignore reviews that I've been added to. 21:53:08 thingee: something like the api_wg does, alert one week prior to merge 21:53:13 and wait as needed 21:53:23 I can control *starring* so I use that to mark them. 21:53:26 thingee: there will be chasing down no matter what you do 21:53:36 also because gerrit subscribes you to every change where you comment, the subscription list piles up very quickly 21:53:38 Or, meeting that results in one week final comments to merge 21:53:42 thingee: so the Cross prj liaisons idea is good from that perspective 21:53:53 nikhil: but when do they call that? It has been sitting with no consensus or little? 21:53:57 fungi: i don't disagree, i'm just thinking about smal pieces for the liaisons. to aid in gaining visibility. 21:54:29 bknudson: +1 21:54:57 it may increase visibility, but i suspect it will increase it so little in the right places as to be a negligible gain for perhaps substantial effort 21:55:11 thingee: propose, give two weeks (alert liaisons right then -- whatever means of communication), wait to see any major blockers, call a meeting mid way (one per week) and merge soon after fornight? 21:55:26 thingee: if you don't want to wait the comments either slowing down or ramping up, you gotta have some timeout there when you just make the call and then in the meeting decide if it is going to merge or not 21:55:27 and since it's not really possible to measure whether it's effective, you'll never know if it's actually worthwhile 21:55:31 I think we should try out the liaison idea and see how it goes. 21:55:56 cross-project-spec liaison? 21:56:22 yes, having cross-project liaisons. 21:56:22 seems like an ok name. 21:56:26 The meeting is for consensus. Those who turn up, or comment in following week have enough interest to participate. Meeting determines -1 for changes, -2 for no, +1 for minor changes, +2 iy's gonna happen unless somebody finds a really big hole. 21:56:26 i guess i'm still a little fuzzy on the liaison proposal, and what's being liaised anew 21:56:31 nikhil: I can work with that process. 21:56:33 we already have cross-project liaisons 21:56:49 a variety of different kinds of cross-project liaisons in fact 21:56:56 next question ... is that group (x-proj liaisons) good enough to make the decision of approval or do we still need to roll them through tc? 21:57:15 cross-project-spec or cross-project-activity or whatever works. 21:57:23 x-prj-specs-chasers 21:57:28 ttx: ^ 21:57:38 yeah, it seems like this liaison proposal is cross-project specs specific 21:57:56 fungi: yes just specs. we can be specific about that in the name 21:57:56 that's the way i read it 21:57:59 rather than just "all things cross-project" 21:58:08 ++ 21:58:14 which will rathole very quickly 21:58:20 so we're defaulting back to ptl again for cross-project-spec liason? 21:58:32 fungi: I think a bit more than spec and a lot less than all things x-prj 21:58:32 I think the group can roll, and appeals can go through TC like always 21:58:33 jokke_: as I understood we need someone with +2 abilities. That would still involve the TC 21:59:15 ok I have things to work with here. 21:59:17 for example, affecting group of projects (say nova, neutron, keystone, docker) but not others 21:59:19 thanks everyone for the help 21:59:30 gordc: yeah, i think all cross-project liasons, including the new one for cross-project specs, default to ptl unless they delegate to a volunteer 21:59:37 you could have some x-prj-specs-chair and give that person +2 21:59:43 fungi: great. 21:59:45 ok, next one isn't tc supposed to be the representation of technical community and why we don't leave those specs purely to them? 21:59:46 collecting consensus like I do for the tc 21:59:55 #action to finalize cross-project spec liaisons in email and whatever other document written needed 21:59:57 I mean making the call when it's apropriate? 22:00:09 #undo 22:00:09 Removing item from minutes: 22:00:18 #action thingee to finalize cross-project spec liaisons in email and whatever other document written needed 22:00:24 Yeah, what ttx said. If just a few projects, +1 from ptls = chair +2 22:01:05 jokke_: here it was more stamping PTLs consensus, not sure that's a great use of TC time 22:01:05 jokke_: I think the TC still needs insight from individual projects? 22:01:06 and at the chair's/proposer's discretion which ptls constitute a suitable quorum 22:01:53 1/ TC members can comment like anyone else on the spec. And (2) issues with cross-project-specs team "decisions" can be appealed to the TC 22:02:04 Yes. Trust rather than untrust 22:02:05 thingee: so we let them to make sure that they get that insight :P 22:02:22 Lets put TC to work for their position! ;) 22:02:32 removing teh TC from the cross-project spec loop is one of the "stepping out of the way" policies I wanted to push 22:03:08 jokke_: I still think the TC members should chime in on those specs. They don't HAVE TO but they SHOULD 22:03:20 I still will. 22:03:23 I do 22:03:42 ok like I said I have some stuff to work with. we can continue discussions in the thread as I finalize things. 22:03:47 and we're out of time 22:03:51 thanks everyone 22:03:52 I just don't think the "when ready ping the TC for rubberstamping" is a great proces 22:03:59 +s 22:04:20 #endmeeting