19:00:10 #startmeeting Ansible Core Meeting 19:00:10 Meeting started Tue Feb 7 19:00:10 2017 UTC. The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:10 The meeting name has been set to 'ansible_core_meeting' 19:00:37 #chair abadger1999 allanice001 bcoca jimi|ansible jtanner mattclay nitzmahone ryansb 19:00:37 Current chairs: abadger1999 allanice001 bcoca gundalow jimi|ansible jtanner mattclay nitzmahone ryansb 19:01:42 hi 19:01:44 * mattclay waves 19:01:47 Feb's agenda https://github.com/ansible/community/issues/150 19:01:51 hey team 19:02:00 Óla 19:02:00 Hello ryansb :) 19:02:11 is present and lurking 19:02:50 bloop 19:02:56 MichaelBaydoun: hey, long time no see 19:03:06 * gundalow is just looking through the agenda for actionable stuff 19:03:15 * sivel is here 19:03:25 sivel: Thanks for updating prbyfile 19:03:39 #topic extending the module "shipit" workflow to non-modules, 19:03:41 oh, I totally forgot to check if it was working 19:03:42 gundalow: lol 19:03:46 https://github.com/ansible/community/issues/150#issuecomment-277025899 19:03:54 sivel: "push and forget" 19:04:05 abadger1999: You around? 19:04:13 yep 19:04:22 about that metadata ... 19:04:29 All approved. We'll start with contrib/inventory as most of those are community maintained as it is. * * Will come up with a list of dynamic inventory proposed metadata for next week. 19:05:16 bcoca: ^ You started a spreadsheet for that. Status for the commuinity? 19:05:31 I think he's just headed for lunch 19:05:49 skip it then 19:05:57 k 19:06:01 OK 19:06:31 #action bcoca to update us next meeting 19:06:54 Do we have enough people to vote on Update assemble to allow alternate source of files 19:07:08 Yeah, we can continue to collect new votes from people. 19:07:10 man, didn't we argue that one enough? 19:07:24 "Right now the decision could be weighted by which committers were attending the meeting so we'll ask for more votes next meeting before making a decision." 19:07:38 gundalow, jimi|ansible, mattclay, sivel, (other committers :-) 19:07:38 hum, no extra people, here, so skipping 19:07:44 oh 19:08:10 * gundalow is a solid +0, I don't enough about use case/impact 19:08:14 I say, -1 19:08:25 Another -1 here fwiw 19:09:11 -1 for me as well 19:09:21 +0 19:09:28 alikins: ah -- you changed your vote? 19:09:34 wait, which vote? shipit? 19:09:50 sorry, I didn't update topic 19:09:59 #topic Update assemble to allow alternate source of files 19:10:00 haha 19:10:04 alikins: https://github.com/ansible/community/issues/150#issuecomment-277026033 On assemble allowing alternate sources of files: https://github.com/ansible/ansible/pull/19500 19:10:25 ah. +1 on assemble, -1 on shipit 19:10:41 There are many solutions to the problem. I don't like the solution, but I am more for not making a change 19:10:50 19:11:08 My -1 is for assemble 19:12:08 I agree with sivel here, other solutions provide sufficient means to solve the problem, without introducing more 19:12:19 code 19:12:36 Okay, we're at -1 (3), +1 (1) +0 (3)... I think that's enough to make the decision? 19:13:10 7 votes, only one yes 19:13:13 so overall, we are at a -2 ? 19:13:24 I say, that is enough 19:13:31 I'll write up the rejection of the feature. 19:13:36 #halp 19:13:43 #help 19:14:11 #agreed 7 votes, only one yes, rejected 19:14:19 In the future we probably should keep better track of how many active committers we have for cases where we feel the need to vote. (for some workable definition of active committers) 19:14:23 #action abadger1999 to write up rejection 19:14:42 abadger1999: Does that follow up on BlueJeans chat? 19:14:43 could use github's reactions to make it simple 19:14:51 gundalow: yeah, likely. 19:15:12 personally I like seeing a comment of +1, 0, -1 that gets updated with names 19:15:41 podlesh: You around? 19:15:41 the bot can display which comitters reacted in whichever way in the bot_status output 19:16:03 #topic #19707 (enhanced rolling updates) 19:16:04 *shrug* just a thought 19:16:14 yes 19:16:24 https://github.com/ansible/ansible/pull/19707 19:16:42 hum, do we need bcoca and jimi|ansible 19:16:50 jimi|ansible or bcoca^ We need one of you here for this 19:17:15 hum, they both seem to be offline 19:17:29 #info need jimi|ansible or bcoca, nether are around 19:17:35 podlesh: sorry, false alarm 19:18:02 ok, next time then :-) 19:18:05 * abadger1999 pinged them internally too just in case they're near the keyboard but not looking at this channel. 19:18:18 skipping host module as he can't make todays meeting 19:18:19 I also seem to recall dyn inv feedback was requested 19:18:20 here .. no change on my side 19:18:49 "Jan 31 meeting: podlesh has some examples of use case that don't seem to be solvable by merely enhancing sorting and grouping independent of serial. bcoca and jimi-c not present. Will discuss at meeting feb 7" 19:18:51 bcoca: So in 19707... podlesh listed some more examples 19:19:10 https://github.com/ansible/ansible/pull/19707#issuecomment-271683995 19:20:10 yeah, we discussed those serial: 3,2,1 19:20:17 serial can be a list 19:20:37 (back in 5) 19:20:38 yes, but that means playbook contains hardcoded values from inventory 19:20:43 no 19:21:20 you can use min/max and length filters to calculate it based on the groups 19:22:22 I don't think min, max and length are sufficient 19:23:14 but ok, filters can be added, if needed 19:23:19 I'm not a huge fan of the implementation, I don't know what a better implementation would be off the top of my head, but currently it feels...duct taped on 19:23:33 probably a strategy plugin 19:23:43 that sounds reasonable 19:24:35 serial: " {{ ['a','b','c']|length ,[groups['a']|length, groups['b']|length]|min}} " 19:24:53 ^ but written right 19:25:02 that's no sufficient, I don't know how many groups there are and what names they have 19:26:24 at one point you need that info to run the play .... 19:26:51 yes, in the inventory 19:26:53 yoru serial group by wont work either in that case 19:27:06 yes, it does work 19:27:29 I think one of the things I don't particularly like is it's openendedness. It's not super obvious what the outcome will be 19:27:30 2 assumptions, a given host is only in 1 group (which is already false as 2 is minimum) 19:27:32 example output: https://github.com/podlesh/ansible-feature-test/tree/master/groups 19:27:59 no, I don't have that assumption - groups are not even neccesary 19:28:13 I would be much more in favor, or something that is more well defined, say, a way that explicitly says something like: Interleave by groups 19:28:15 2 if no using groups you assume the varaible is availabel for all hosts 19:28:23 as opposed to some templating that decides, that isn't really obvious 19:28:23 another sample, that does not even use groups: https://github.com/podlesh/ansible-feature-test/tree/master/variable 19:29:11 yes, I agree that the universal template is quite too generic 19:29:33 As it is, I have no idea what the outcome would be by just looking at the play 19:30:32 We tend to get lost here sometimes, but I still like to go back and think of a playbook as "executable documentation" 19:30:37 and this is not self documenting 19:30:44 but I have no better idea how to specify how should they be split... 19:32:39 i really dont see it going forward in current form, its too contrived and there are workarounds for any case i can come up with 19:32:47 either by alternate grouping or inventory 19:32:54 and serial list + calcluations 19:33:08 Just throwing out some ideas off the top of my head, but if `serial` could be an "explict" set of hosts for chunking 19:33:37 group_by directive would make more sense ... but .. groups! 19:33:58 i see a 'constructed groups' inventory plugin as a better solution to all this 19:34:20 hmm, I should have chosen different name... 19:34:38 i would say same to 'clustering' 19:34:49 are we tryikng to shoehorn a feature into the wrong concept? 19:34:53 I don't think we are anywhere near consensus here, and I don't think we will be. At this point, I think the agreement is that we don't like the current implementation 19:34:56 abadger1999: I think so 19:35:10 i agree with sivel 19:35:27 ok, so should I try to implement strategy plugin for sorting? 19:35:45 no, as i said in previous discusison sorting is different issue, related, but diff 19:35:54 you want clustering, which requires sorting, but it is not JUST sorting 19:35:59 I'm still not sure that a strategy plugin to do this would be something we would accept 19:36:25 It could be shipped on galaxy, though (since it would then be a plugin) 19:36:33 a 'sort' directive is something i have been contemplating for long time, but would not 'cluster' the hosts to serial, just the inventory processing order 19:36:57 overall, it still does feel kinda edge case, and I'm not sure I really think it's something I'm particualarly interested in 19:37:05 If it's strategy, then it's really operating on the hosts: field, not on serial right? 19:37:25 abadger1999: it gets both 19:37:44 edge case / niche 19:38:03 from the hosts:, construct sets of targets to be executed together. 19:38:14 It might even disregard (or error) if serial were also given. 19:39:06 so my stance is: It feels a bit shoehorned as is, but overall even with a better implementation, it feels very niche to me currently, and I'm not sure I would be in favor at all 19:39:36 something provided externally, maybe via galaxy, I'd be happy with 19:40:04 which somewhat limits the implementation to a strategy plugin 19:40:59 Once we can install plugins from galaxy in a propr manner, I'd be happy with it on galaxy. If we have metadata on strategy plugins before then I'd probably be okay having it in the repo as a community plugin. 19:41:38 I suppose at least, that provides direction here either way 19:42:05 ok, I'll try to find something 19:42:27 and consider the PR rejected... but thanks for considering it, in any case 19:42:36 I think as a language feature (serial_grooup_by:) there's a lot of maintainance drawbacks but as a plugin, it's at least isolated and we can say "podlesh maintains that, not us!" ;-) 19:42:55 Okay. 19:43:03 podlesh: Thanks for understanding. 19:43:45 podlesh: to clarify, i do see the usfeulness of your intent, but the current implementation seems forced 19:43:53 #action serial_group_by PR rejected. May revisit the idea if it gets implemented as a strategy plugin. 19:44:18 a 'strategy: cluster' might make a better way to do this and even include in ansible, 2 things, sorting i would make a new directive, the cluster condition ... we dont have good way of passing this in currently 19:45:14 worst case a 'sort' AND a 'cluster' directive that can expose data to compute in 'serial' 19:47:00 should we tackle some more items on the agenda? 19:47:30 ok, I understand, and I'll look at it... 19:47:56 you can move on :-) 19:48:14 podlesh: pinged jimi|ansible he'll also look at it, we all would like to support some of the use cases 19:49:29 .. expand host patterns [groupa:groupb]one 19:51:25 As we're getting later, we should probably look at https://github.com/ansible/community/issues/150#issuecomment-277304534 19:51:45 #topic How to agree on proposals? 19:53:01 So last week, (I think it was in the testing group meeting) there was talk about enforcement of style rules on code. 19:53:05 the original proposal for proposals (meta) ... left many thnings undefined, i think its time we do define them 19:53:36 ^ in that meeting a proposal got 'retroactively' created + agreed + implemented, which looks like a bad use of the process 19:53:42 There was the impression that new files had been decided before but hadn't been properly documented. 19:53:49 And also a proposal for existing code. 19:54:47 bcoca: and I discussed this a bit, and we shoehorned what was effectively a "core dev directive" into the proposal process. We all agreed to push it through, but still gave the impression of a proposal in the current form, but without giving anyone time to weigh in 19:55:08 so prposal workflow calls for a 'creation-> make public->get feedback ->schedule for core meeting discussion -> approve or reitarte previous steps -> in progress - >done/denied 19:56:00 to avoid taht situation i prpose having a 2-4 week 'make public' before it gets scheduled for meteting/approval, this gives community time to weigh in 19:56:12 ^ we also need more labels and to clearly define meaning and stage 19:56:44 We also need to publish a list of proposals that we're going to be looking after that time period 19:57:19 Right now, you'd have to watch all proposals to know what we might decide to talk about. 19:57:19 meeting ticket works for that 19:57:29 I would say we look at pep-426 for guidelines on meta implementation, which should become part of the proposal 19:57:30 ^ proposal advocates should schedule once the 'period is passed' 19:57:51 bcoca: no.. needs to be before the period starts. 19:58:12 abadger1999: ??! so we 'agree' to it before anyone gets input? 19:58:29 Right now we have a ton of proposals in various states and no commitment on our part as to when they will be reviewed and approved or rejected. 19:58:48 which is why i prpose clear labling and workflow 19:58:54 bcoca: we need to tell people which of those to pay attention to because they are going to be discussed immienently. 19:59:18 abadger1999: i would reverse that, proposal authors need to advocate 19:59:33 ^ see workflow above and robyn's proposal proposal 20:00:12 So something like proposal author or we decide Proposal/50 is ready. Need to announce it somehow and somewhere. Input is gathered for 2 weeks and the proposal is updated. proposal author (or we) push the proposal onto the meeting agenda. Proposal is discussed at meeting and eventually approved or rejected. 20:00:12 a) create b) engage communicy c) public feedback d) schedule for meeting e) here WE get involved and discuss approve/reject/send back 20:00:52 Possibly use community meeting as a platform where proposal authors can table their proposals, and that sets the workflow / agenda ? 20:00:56 f) its approved g) someone is working on it ... then done/rejected 20:01:14 S/sets/starts 20:01:20 i think it's difficult to make any system work if the system isn't the full time job 20:01:44 jtanner: volunteer systems also work, jsut not the same way 20:02:15 jtanner: or you are advocating for killing proposals process? 20:02:27 no, just saying it's never going to be perfect because we have other jobs to do 20:02:53 bcoca: I think we're talking about the same workflow... I'm just wanting more clarity on [b] and [d]. 20:03:01 not looking for perfect .. just not 'completely disorganized' 20:03:26 abadger1999: i would leave everything before e to author/advocates 20:03:40 ^ as jtanner points out, we dont have the time to chase them 20:04:36 bcoca: Well... according to the "exact" steps you wrote down... proposal/50 was good all the wat to (e).... 20:04:50 abadger1999: if author nor advocates care enough to advance it .... 20:04:56 So that's why I think there needs to be more details there. 20:04:58 abadger1999: no, there was no public period 20:05:11 bcoca: you didn't say that there needs to be in your *exact* steps. 20:05:23 c) public feedback 20:05:24 bcoca: You said "engage community" 20:05:29 ^ also mentioned 2-4weeks 20:05:30 "public feedback" 20:05:44 Those were done for proposal/50 via the testing working group meeting. 20:05:46 yes, period in which you allow the public to post feedback 20:05:53 That's why I think we need more details. 20:05:57 What's a proper venue? 20:06:04 What's the proper time period? 20:06:06 abadger1999: they were not done IN proposals 20:06:17 i think 4 weeks is good, others might find that too long 20:06:37 I think we need to answqer both of those questions in the meta-process. 20:06:44 Yeah, one week. 20:06:52 b) community engagement => AT LEAST email to ansible-devel, 'public period' should start from taht date 20:06:59 I can stretch to your 2 weeks. But 4 weeks is too long. 20:07:27 Because the end of hte 4 weeks, is just the beginning of the drafting process... it then goes to use where we ask for more changes. 20:07:28 i think that at 4 weeks, without (e) being met, proposal rejected 20:07:43 2weeks tends to be short as people vacation or have projects and cannot pay attention, most proposals are impactful enough to require broad feedback 20:08:58 bcoca: 4 weeks is way too long for the release schedule that we drive ansible at. 20:09:06 We could ioncrease the release cadence. 20:09:26 I think 4 weeks is too long, for the reasons abadger1999 mentions. If you don't get it going really early, you can't do anything for the current release 20:09:27 Or we could process proposals in a batch at a set time in the release cycle. 20:09:34 current = next release 20:09:39 considering teh quick cadence, i dont see such big issue 20:09:48 if proposal misses current, it hits next 20:09:57 But if we do that we want to do those changes as well. 20:09:59 if we had longer release cycles .. i would consider shorter time frames 20:10:20 i feel like we're always releasing 20:10:28 lets do thsi 2-4weeks variable depending on proposal scope? 20:10:28 jtanner: +1 we are. 20:10:49 1-3 weeks depending on proposal scope. 20:10:59 with 1 week and 3 weeks being the outliers. 20:11:01 1 seems too short 20:11:09 bcoca: depends on the proposal. 20:11:13 2-4 with 2 and 4 being outliers? 20:12:00 1 - 3, with week 2 being a decider if week4 needs to be added / considered ? 20:12:01 1-4 with 1 and (3-4) being outliers? 20:12:32 defaulting around 2 with flexibility to go less is what I want. 20:12:35 2 weeks, expandable to 4 if we deem its needed? 20:12:48 1 week seems rushing it 20:13:20 On small proposals, you may not need week2 20:13:21 bcoca: There are lots of proposals that don't need more than 1 week. 20:13:22 If something feels like it should be 1 week, maybe it isn't significant enough to need a proposal? 20:13:24 ^ that is how they passed patriot act 20:13:37 Also, in my opinion, and not sure if we want to get into it, but there should be a process for subverting proposals. Not sure it even needs called out 20:13:41 mattclay has point 20:14:06 if you MUST pass it in one week .. its not a prposal worth issue 20:14:11 mattclay: Yes but proosals are the only way the community has of getting the core team to agree to something. 20:14:38 abadger1999: its also how we push design decisions that affect the community out for public consultation 20:14:39 beyond the core team, they also allow subject matter experts to weigh in 20:14:40 abadger1999: What about showing up at core team meetings on IRC? 20:14:44 ansible-config/ansible-inventory as examples 20:14:50 mattclay: so right now, proposals are the way we get small things as well as large things onto our radar. 20:15:06 abadger1999: for really small things, we still have feature ideas 20:15:08 +1 mattclay 20:15:19 Also add to core agenda 20:15:27 mattclay: that is requriement of proposals process i want 20:15:49 'creation-> make public->get feedback ->schedule for core meeting discussion -> approve or reitarte previous steps -> in progress - >done/denied 20:16:10 proposal ONLY gets apprpoved in public meting 20:16:46 mattclay: Both of those are on iRC... so people who don't do IRC (or are in the wrong TZ's) are left out. 20:17:23 abadger1999: that is why we have 2 meetings at diff times, irc is free and not a barrior, if people wont go on irc to push their proposal .... well, it was not that important to them 20:17:46 IF author needs special meeting time, i think we can add/change one of existing for a week 20:18:00 Also, if community is involved, someone will be awake and online for the irc meeting 20:18:17 ^ probably, specially with proposals that have wide intereset 20:18:20 We probably need either the flexibility to have shorter proposal periods, or an alternative to the proposal process for things that aren't "proposal worthy". 20:18:21 bcoca: Although I want that to be rationale, I klnow that it isn't. 20:18:37 *I klnow that it unfair 20:19:14 so we dont want public consultation, just want to get stuff done ? then why have them at all? 20:19:19 for instance, both of our meeting times are bad for AUS. Some people may only care about Ansible for work. Others may only be able to use IRC when not at work... 20:19:43 abadger1999: i'm willing to be flexible and schedule speical meetings for those cases 20:20:08 at least you and I have very strange sleeps schedules which can accomodate them, the problem is when we need bigger quorum 20:20:12 bcoca: I think we're confused about what is being talked about... 20:20:17 Also, nothing prevents those people from reaching out to core when they're online 20:20:25 ^ which is why the public feedback process is there, allows ASYNC comments 20:20:28 outsi 20:20:38 Outside of normal meeting times 20:20:53 so even people that cannot make IRC can make opinions known on proposal ticket 20:21:00 I think roughly what we are saying here. Items claiming to be proposals, should give the community time to comment, and to know when it will be discussed in a meeting 20:21:03 bcoca: mattclay is saying that irc meetings are an alternative to proposals for the little feature request... I don't think we want to schedule special meetingsa just for small, posibly trivial proposals. 20:21:04 that is why 2-4 weeks gives AMPLE feedback opportunity 20:21:13 sivel: yep 20:21:25 Let's not make this too complicated :) 20:21:27 abadger1999: feature idea ticket 20:21:37 bcoca: which gets ignored. 20:21:44 just like proposal tickets get ignored. 20:21:51 abadger1999: both require advocacy 20:22:13 Right. And how do people advocate for a feature ticket? By making a proposal ticket. 20:22:19 you can bring them up to these meetings in same way, proposals just have higher impact and should be open for more discussion 20:22:22 That's what we've been telling people to do. 20:22:29 abadger1999: no, that is misuse of propsals 20:22:32 there is scope 20:22:34 @mention in agenda, and whether you'll be attending, or a time you'll be online to discuss proposal 20:22:44 'change the eror message to be clearer in vault edit' is NOT a proposal 20:22:44 bcoca: it's what we've been telling people to do. 20:23:12 abadger1999: not all, there are plenty of feature ticktes open and we've even discussed in previous meetings 20:23:20 ^ being opened 20:23:21 Even if someone can't attend on IRC and doesn't want to use the mailing list, they can put an item on the agenda to say "hey, this feature ticket could use your feedback, I've given mine in the ticket already". 20:23:32 exactly 20:23:43 +1 to that 20:23:54 abadger1999: we dont have 1 processs fits all into proposals ... i tink this is where our disagreement comes from 20:24:02 we are NOT pushign all requests there 20:24:07 Anyhow... I'm feeliong that we need a proposal to revamp all of this. 20:24:13 that was not what ther purpose was 20:24:15 To lay out how it all fits together. 20:24:39 bcoca: that is nolt the purpose that you saw. 20:24:40 abadger1999: that is why ipointed to robyn's doc, we just need to fill in details, it already had most of this 20:24:59 A proposal should typically be large scale work, that we want to see as a proposal, before there is code 20:25:00 That was the purpose that some people saw because that was what they were telling people to use it for. 20:25:04 abadger1999: not sure what you think i saw 20:25:42 not sure who/how, for me it was clear that anything that requried invasive changes or was a big feature design, is a propposal 20:25:51 small features or non invasive ,, feature idea 20:26:06 when did it get decided that all change requests were porposals? 20:26:10 ^ i missed that meeting 20:26:12 Definition of "big" is the problem. 20:26:23 anyhow... Write a proposal. 20:26:44 I think roughly, in a way, we don't want people to spend a bunch of time writing code on a "big" change, if in the end we decide we don't want it 20:26:47 i've written several, those that i thought were big enough scope and needed discussion, again, ansible-config, invenory plugins, etc 20:26:51 Think of the serial_group_by 20:26:59 I think it should have an entry point to the process and clear escalation path. 20:27:01 ^ that would have saved him a lto of time 20:27:12 abadger1999: please define 20:27:14 bcoca: no -- I mean, write a proposal to change the way we process features and proposal. 20:27:27 https://github.com/ansible/proposals/blob/master/proposals_process_proposal.md <= already exists 20:27:34 Perhaps a good measure of "big" is time involved to make the change. Since reverting is easy, spending a small amount of time on something that we reject isn't a big deal. 20:27:41 im saying we need to update/clarify it 20:27:55 mattclay: that is one measure, the other is impact 20:28:12 I want to implement Foo. What is my entrypoint to find out if Foo is acceptable? What is my entrypoint to find out if my implementation of Foo is acceptable? 20:28:22 depends on what foo is 20:28:32 i cannot give you an answer that works for all cases 20:28:39 i dont think anyone can 20:28:56 How do I get people to review Foo or to work on Foo (in case it is a feature I am not going to code0. 20:29:09 advocate 20:29:17 bcoca: Exactly! "depends on what foo is". 20:29:27 i don't think proposal is going to get one of us to write it for someone else 20:29:34 that's roadmap from $CORP 20:29:49 So we need a path for the user to define Foo and then present it to someone who can say => Advance this feature Foo by doing XXX, then YY, then ZZ. 20:30:12 proposals are a godo way to make complex ideas known and get feedback before any code gets written, they arenot a corset to prevent people from writing code 20:30:17 versus, This feature Foo falls into this other category, advance it by doing YY and then ZZ. 20:30:50 abadger1999: that is what ansible-deve/irc and feature idea tickets are for, when we triage and see 'this shoudl be a proposal' we give that feedback 20:31:11 bcoca: Ugh.... that does not happen right now. 20:31:17 abadger1999: why not? i do that 20:31:28 Then you should tgriage all tickets. 20:31:31 please show me case? 20:32:00 Anyhow... This is a large change.; I think that you should make a proposal for iot and then we can figure out he details. 20:32:03 i'v responded to eamils in ansible-devel, feature tickets and to irc saying 'open feature idea ticket or proposal ticket' ... am i only one? did you all decide to remove 'feature idea' tickets? 20:32:09 WHEN did that get decided??!??! 20:32:27 When did what get decided? 20:32:32 abadger1999: not sure when this 'ONLY Proposals' happened 20:32:43 THAT SI WHAT IM ASKING! 20:32:50 It didn't. 20:32:55 That's not the case. 20:32:58 so why do you say that is the reality?! 20:33:22 Here's what I see happens. 20:33:27 Submitter files a feature ticket. 20:33:34 (Case A) It gets ignored. 20:33:40 End of story 20:33:52 that is not always true 20:34:07 (Caee B) User drops by on IRC to ask what's happening with ticket 12345 20:34:07 i've implemented many feature idea tickets, ive merged OTHER peole implementing them also 20:34:15 i've redirected them to proposals also 20:34:21 (CaseB.1) Someone says open a Proposal 20:34:28 Proposal ticket gets ignored 20:34:42 (Case B.2) Someone says, I'll put that on the meeting agenda. 20:34:53 abadger1999: tickets get ignored .. that is the whoel point of advocacy .. there is no human way we can do them all 20:34:59 Ticket gets reviewed and accepted or rejected. 20:36:00 (Case B.3) Someone deals with the ticket then and there. 20:36:02 It would probably help to document the need to advocate for a proposal/feature and put a link to that doc in the issue template. 20:36:26 mattclay: https://github.com/ansible/proposals/blob/master/proposals_process_proposal.md <= has section about that 20:36:32 "Proposals use public meetings as a mechanism to keep them moving" 20:36:43 Anyhow.... what we need is to tell people (*) To advocate, and (*) How to advocate. 20:36:56 New proposals are explicitly added to the public IRC meeting agenda 20:37:00 bcoca: Which is untrue. 20:37:04 Note: ample feedback in the comments of the proposal issue should allow for folks to come to broad consensus in one way or another i 20:37:08 strike what I just said. 20:37:14 Your clarification makes it true 20:37:51 i'm saying we need to clarify the document, make it more prominent, fill in gaps ... not sure why you are opposing that complaingin about the non process we dont have? 20:38:11 im confused as to where you want to get to 20:38:16 bcoca: make a proposal for it. 20:38:17 i want a clear/public proposal process 20:38:26 Then we can work out the details and approve it. 20:38:30 As do i. 20:38:34 ^ THAT DOCUMENT, just need to add schedule/tags and hints on how to advocate 20:39:08 abadger1999: i've been discussing teh ony doc we had, you seem to have been discussing the process you percieve ... i really cannot reconcilate both 20:39:55 bcoca: right. So make a proposal and then we can work out what needs to change. 20:40:03 we have not been following the doc perfectly, that is one reason i brought up this topic 20:40:21 Currently, that document is for some fantasy workflow that no one follows. 20:40:29 we follow most of it 20:40:33 at least iw as 20:40:49 I propose a change to the proposal which we can discuss over the next 2 - 4 weeks... 20:40:53 :P 20:41:02 it is more proactive on our side than we are, i propose moving the 'push' to author/advocates 20:41:19 to make the workflow more realistic 20:41:38 alikins: +1 ;-) 20:41:45 allanice001: I mean :-) 20:42:36 i have no issue with that, i just wanted to discuss how peopel wanted to imrpove it and how to make the process more 'community friendly' ... not sure how that devolved to this ... 20:46:10 From my POV, I think the biggest impact will be to drive author / advocates here 20:46:53 Using podlesh as an example, we were able to discuss a deep impacting feature extensively over 2 - 3 weeks 20:47:03 Same can be done with proposals 20:47:09