20:06:08 <gregdek> #startmeeting community-working-group
20:06:08 <zodbot> Meeting started Fri Mar  4 20:06:08 2016 UTC.  The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:06:08 <zodbot> The meeting name has been set to 'community-working-group'
20:06:14 <gregdek> #chair rbergeron
20:06:14 <zodbot> Current chairs: gregdek rbergeron
20:06:24 <bcoca> should core be in this?
20:06:38 <gregdek> bcoca: today yes, because the agenda is proposals!
20:06:42 <gregdek> In general... maybe?
20:06:47 <bcoca> /quitandrun
20:06:53 <bcoca> he
20:06:53 <gregdek> We will get better at posting agendas. :)
20:07:14 <bcoca> was about to write one, but then saw robyn's metaproposal on proposals
20:07:37 <gregdek> #topic proposal metaproposal
20:07:40 <gregdek> :)
20:08:09 <gregdek> ansible/ansible#14802
20:08:19 <gregdek> OK, so!
20:08:26 <gregdek> chouse we're convening now
20:08:28 <rbergeron> This is a thing!
20:08:32 <chouse> here
20:08:40 <rbergeron> #link https://github.com/ansible/ansible/pull/14802
20:08:46 <gregdek> (thanks rbergeron)
20:08:48 <gregdek> ok.
20:08:57 <gregdek> rbergeron has the floor :)
20:09:03 <rbergeron> #info robyn (that's me!) proposed a proposals process today ... via proposal
20:09:09 <rbergeron> Note that feedback should go in teh PR
20:09:20 <rbergeron> but happy to field some questions here and now, directly or indirectly related :)
20:09:25 <rbergeron> though i don't want to spread the conversation too much
20:09:37 <rbergeron> #action gregdek to link this meeting in the PR comments just for transparency, yo
20:09:39 <gregdek> (we can always feed it back into the pr as needed)
20:09:51 <bcoca> what does 'notify the community' involve?
20:10:01 <gregdek> my take: email ansible-devel
20:10:05 <rbergeron> chouse: didyou have questions on this lovely topic?
20:10:17 <chouse> maybe.
20:10:19 <gregdek> to notify the community that the proposal exists
20:10:29 <chouse> mostly how does a proposal get approved?
20:10:39 <chouse> and when does one know that it is approved?
20:11:13 <rbergeron> So:
20:11:27 <chouse> and if one is writing code how does one let the world know about *code in progress*
20:11:38 <rbergeron> There is the idea of "voting", either by appointed/ listed humans, or by "whoever is present"
20:11:41 <rbergeron> Or
20:11:57 <rbergeron> There is the idea that there will be loose consensus and nobody is vehemently disagreeing.
20:12:20 <bcoca> so basically when bcoca doesn't protest?
20:12:22 <gregdek> re: "writing code", seems like part of the reason for having a proposal is to have clarity *before* writing code. If you're ready to write code, seems like regular PR process would apply.
20:12:22 <rbergeron> Either way: the meeting organizer / chair can ask if anyone disagrees, or if those present agree, and then mark it as agreed.
20:12:31 <rbergeron> #agreed Greg is crazy.
20:12:35 <gregdek> HEY
20:12:38 <gregdek> -1
20:12:45 <rbergeron> #info using #agreed puts it in the notes, and then it is known to be approved.
20:12:50 <bcoca> he is not crazy, the lack of head pressure is making him loopy
20:12:55 <rbergeron> #info that was an example. Greg is not actually crazy.
20:13:03 <gregdek> (sigh)
20:13:05 <rbergeron> #info He might be forgetful, because he doesn't remember how to use the #undo command.
20:13:21 <rbergeron> #info he might be my boss, so i should stop :)
20:13:28 <rbergeron> Anyway:
20:13:53 <rbergeron> *who* can decide could be a thing, but i expect that by the time someone is ready for a group to review it, there is probably loose agreement that it's probably going to be okay anyway.
20:13:53 <bcoca> on the question of where/how proposals live, almsot tempted to say it's own repo as they'll add a bit of structure in the end to ansible/ansible with /pending /approved /done /etc
20:14:03 <rbergeron> But having a stamp on it is helpful.
20:14:30 <gregdek> Yeah, +1 at this point to new repo maybe
20:14:53 <chouse> wait. put proposals in their own repo?
20:14:56 <rbergeron> So I can make a PR to that effect.
20:14:58 <bcoca> then the organization/workflow of the proposals can take more directions, no restriction on the ansible/ansible existing flow
20:15:04 <bcoca> s/on/from/
20:15:06 <rbergeron> chouse: see the comments in the PR for more context.
20:15:21 <abadger1999> well... once approved, where should proposals live?
20:15:32 <rbergeron> HAS EVERYONE READ THE PROPOSAL PROPOSAL
20:15:34 <rbergeron> just asking
20:15:35 <rbergeron> :)
20:15:35 <abadger1999> I was thinking alongside the module guidelines/contributing/coding docs.
20:15:54 <chouse> i'm reading it...
20:16:15 <rbergeron> my suggestion was either in /roadmap (or maybe version #)
20:16:17 <bcoca> abadger1999: well, many stages, proposed|revised/aproved|rejected/workingonit/done
20:16:22 <rbergeron> greg suggested perhaps a specs directory
20:16:33 <gregdek> yea, srvg also brought this question up in the comments of the proposal's PR
20:16:38 <rbergeron> Because at some point , it's no longer a proposal, it's a thing in motion.
20:17:16 <rbergeron> And often associated with a release.
20:17:24 <gregdek> quoting rbergeron from the proposal discussion: "Just trying to keep in mind the perils of having 14 possible places for discussion, and if multiple subsequent PRs need to be opened to make updates to the proposal before it is ready to be approved, then maybe the best idea is to have a proposal be a PR straight to "roadmap" or "specs", and upon approval then
20:17:24 <gregdek> have the PR merged."
20:17:46 <rbergeron> and not in ansible/docs.
20:18:04 <rbergeron> Because I think that means it would get shipped with a release, and that's sort of disatracting / cluttery for the user experience, imo.
20:18:19 <bcoca> almost sounds like we need sivel's 'github by file' tool just to keep track
20:18:28 <gregdek> lol
20:18:52 <gregdek> the eternal challenge of lightweight vs. complete
20:19:10 <abadger1999> note ansible/docsite (rather than docs) would not get shipped with a release.  those are not in a tarball.
20:19:13 <bcoca> https://ansible.sivel.net/pr/byfile.html
20:19:26 <gregdek> so we need:
20:19:31 <gregdek> * an artifact that is the proposal
20:19:42 <gregdek> * a way of tracking discussions of that artifact
20:19:48 <gregdek> * a way of modifying the artifact
20:20:09 <gregdek> * a way of putting the artifact into buckets (agreed, rejected, etc.)
20:20:25 <gregdek> * a time/place to discuss
20:20:33 <chouse> this sounds more like a waffle card than a thing in github
20:20:51 <abadger1999> I don't htink waffle is public?
20:20:57 <gregdek> Oh yes it is.
20:20:59 <bcoca> yes, ticket system seems to fit in better than a checking
20:21:03 <bcoca> check-in
20:21:03 <rbergeron> abadger1999: it is indeed, at least ours is.
20:21:05 <gregdek> Our community waffle board is public.
20:21:13 <gregdek> (It can be, anyway.)
20:21:31 <bcoca> waffle/trello/github-issues/insetanyhere
20:21:41 <abadger1999> okay
20:21:50 <bcoca> which is a bit of what we were doing already with 'feature idea'
20:21:57 <gregdek> If it's a repo only for proposals, it makes waffle easier
20:22:41 <rbergeron> does that repo just track proposal process, or is it also tracking it to completion along with a release?
20:22:49 <rbergeron> in the course of a release
20:22:50 <rbergeron> ?
20:22:54 <sivel> I think a repo for proposals is a good idea, instead of putting it in ansible/ansible
20:23:04 <rbergeron> proposal progress rather than process
20:23:09 <rbergeron> sigh. words today, they're harrrrrd
20:23:21 <chouse> yeah, agree with sivel.
20:23:35 <bcoca> do we need a repo or a ticket system? cause from list above it seems the latter
20:24:13 <sivel> It's complicated to update a "proposal" by another person, if it is in a ticket system
20:24:18 <abadger1999> we'll need to push proposals to docs.ansible.com at some point and in some hierarchy. (as they'll document things like ongoing best practices as well as things that just have a single well defined point in code).
20:24:25 <sivel> maybe use the wiki capability of github for prposals instead
20:24:39 <rbergeron> sivel: yeah, i feel a bit like that as well,
20:24:51 <sivel> so +1 for wiki :)
20:24:51 <rbergeron> except that wiki in my experience usually means
20:24:57 <rbergeron> "where information kills itself"
20:24:59 <sivel> well, yeah that too :)
20:25:01 <gregdek> Well, I think the distinction between discussion and artifact is important.
20:25:07 <gregdek> wiki munges those together.
20:25:14 <rbergeron> But: lower barrier to entry
20:25:21 <rbergeron> wiki could track state after approval.
20:25:32 <rbergeron> artifact tracks discussion on the way to approval.
20:25:34 <chouse> what if we have one open issue per proposal. the discussion happens in the issue.
20:25:35 <gregdek> and higher chance that someone just tramples on it because WIKI HURR DURR
20:25:50 <gregdek> chouse: I think I like that, and waffle to track, tbh
20:25:53 <rbergeron> After it's approved, discussion isn't really necessary except maybe in the context of the code pr's themselves.
20:26:29 <rbergeron> house: you said that you were having trouble with that though?
20:26:33 <rbergeron> or was that just because lack of clarity?
20:26:43 <rbergeron> typing in issues and not seeing it in the PR or whatever.
20:26:47 <bcoca> abadger1999: proposals make poor documentation, yes, we will need docs in the end but not the proposal
20:26:59 <chouse> well, we close the PRs. so there was no place to have a discussion.
20:27:04 <gregdek> yeah, as of now we haven't agreed on any process at all, so we're all ad-hocking it :)
20:27:21 <bcoca> +1 for wiki, as sivel points out taht is designed for collaborative document editing
20:27:31 <chouse> so thus far, there has been no discussion. just proposal docs.
20:27:44 <gregdek> well, we have some starting points.
20:27:55 <bcoca> well, there have been some comments, both on proposal 'code' and PRs
20:28:13 <gregdek> github, ironically, provides too many choices. :) we must constrain somehow.
20:28:19 <abadger1999> bcoca: ehh.... somewhat agree with you... If you look at the python enhancement proposals they have somethings that are excellent as documentation and some things that are very very pooor.
20:28:20 <rbergeron> And I think we're like, 4 hours into this proposal proposal and it might be worthwhile to see what other people think and feel. :)
20:28:27 <bcoca> i say proposal repo and use wiki format
20:28:33 <chouse> if we leave the PR open, then we can have a discussion up until the thing is approved.
20:28:49 <chouse> once approved, close the PR
20:28:58 <gregdek> you can actually have discussions on closed PRs :/
20:29:01 <bcoca> abadger1999: also diff programming language proposals from utility tool docs ...
20:29:18 <rbergeron> yeah, but any updates to that doc go in a new PR, and then where the ay subsequent discussion go?
20:29:23 <rbergeron> in the new PR? the original PR?
20:29:37 <abadger1999> bcoca: but we're going to have all sorts of proposals... some coding related, some feature related, some that we haven't really thought much about...
20:29:47 <bcoca> ^ that is messy and hard to follow, i thnk wiki is better than PRs chained
20:29:56 <rbergeron> abadger1999: yeah, and that's why i left some of the template open, and provided some suggestions.
20:30:06 <bcoca> before we continue, 'feature idea' is dead then?
20:30:07 <rbergeron> bcoca: but they wouldn't be chained if it was a PR that wasn't immediately merged.
20:30:21 <rbergeron> bcoca: in what way
20:30:24 <bcoca> rbergeron: but once merged?
20:30:30 <rbergeron> bcoca: merge it once approved.
20:30:38 <bcoca> rbergeron: currently 'porposals' were 'feature idea' tag issues
20:30:55 <rbergeron> Of course, then it's not a proposal, it would go to specs or roadmap or whatever.
20:30:59 <bcoca> but they could be 'i want service to find alieans' or very detailed, nothing formal
20:31:04 <rbergeron> all proposals are feature ideas?
20:31:10 <rbergeron> but the code itself is labeled a feature?
20:31:21 <bcoca> that is feature request,
20:31:29 <bcoca> pull request
20:31:31 <rbergeron> bcoca: the thing is that lots of people have feature ideas, but a proposal i think also implies "i'm goign to write the code and here's my plan"
20:31:43 <rbergeron> ah
20:32:01 <rbergeron> well -- we need to define the difference between what should be a feature and what should just be a regular PR.
20:32:03 <abadger1999> bcoca: depends... I think feature ideas that are noncontroversial could be done directly in github.com/ansible/ansible.  We'd have to see that someone has submitted a feature proposal that we want more feedback on and push  them into the proposal process.
20:32:04 <rbergeron> but.
20:32:07 <bcoca> so i ask, where do we draw line? do we require proposals from now on? do we still allow for them in 'free form' in feature ideas?
20:32:46 <gregdek> I think the purpose of a proposal is thus: "I want to work on THING-X, but I want help shaping it (or to tell me not to bother.)" For people who just want to submit a PR, fine, but we may not accept it.
20:33:01 <chouse> +1
20:33:22 <gregdek> That's specifically what dag asked me for, fwiw. "I'm ready to crank on some code, but want someone to tell me it's worth bothering before I write actual code."
20:33:35 <chouse> I want to work on docker, and i need help shaping it. thus proposals.
20:34:04 <rbergeron> maybe we should get dag's feedback :)
20:34:20 <bcoca> he is afk at this time
20:34:32 <gregdek> we can point him to your proposal proposal. :)
20:34:34 <gregdek> So:
20:34:50 <gregdek> bcoca and sivel both +1 wiki. If we said "ok wiki", what would that look like?
20:34:52 <bcoca> he did ask about 'where do i comment?'
20:35:15 <bcoca> gregdek if new repo, its easy repo becomes base of wiki (self hosted github repo)
20:35:20 <chouse> can anyone update the wiki or is that a PR thing too?
20:35:23 <bcoca> kind of like README works now, but with online editing
20:35:24 <rbergeron> I think for "post-acceptance / rejection / code-in-progress / etc,
20:35:32 <rbergeron> that's easy.
20:35:40 <rbergeron> For tracking discussion of the original proposal, maybe less so.
20:35:52 <gregdek> We'd have to set up contributors to the wiki. I don't know if any of the GH wikis are "anyone can comment by default".
20:35:57 <rbergeron> Because i would expect that someone would want to be able to say what they were comfortable committing to.
20:36:19 <rbergeron> Not having something approved after someone edited what the author was going to actually do.
20:36:32 <bcoca> can discuss in wiki
20:36:33 <gregdek> Or it's a PR, in which case, what's the diff between wiki and regular doc with PR additions?
20:36:36 <rbergeron> It's up to the author to incorporate feedback to gain consensus and decide if they want to do the work as recommended.
20:37:24 <bcoca> we can setup wiki to test if it has what we need
20:37:29 <bcoca> teardown if not
20:37:43 <bcoca> i just dont think PR/git system will work well for most
20:38:03 <gregdek> Do we broadly agree that a separate repo is likely the way to go, anyway?
20:38:09 <bcoca> a forum/ticket sytstem with comments would be nice, but really wiki is what is designed for collaborative docs
20:38:17 <bcoca> +1 to sep repo
20:38:23 <gregdek> +1 to separate repo from me
20:38:30 <bcoca> even if later we need to add or link from ansible/ansible/docs
20:38:33 <chouse> What if a proposal is owned by a single person, and all discussion happens in an open issue?
20:38:48 <chouse> +1 to sep repo
20:38:57 <gregdek> I kinda like that, chouse, yeah.
20:39:14 <bcoca> chouse: sometimes discussion will happen later, do we reopen issue? unmerge?
20:39:21 <chouse> i'm happy to be the keeper of my proposals and update them as comments unfold in an issue.
20:39:25 <gregdek> Because anyone can comment in an issue. Lowest barrier.
20:39:51 <bcoca> well, only github users, but i assume that is the barrier to entry already
20:39:56 <abadger1999> no objections to a separate repo
20:39:59 <gregdek> (right bcoca, yes)
20:40:02 <chouse> so discussion happens. i submit a PR to update it. it get's immediately merged. discussion continues.
20:40:17 <bcoca> chouse: were? original or new PR
20:40:25 <gregdek> Issue.
20:40:28 <bcoca> what if the discussion is about your change pr?
20:40:30 <chouse> new PR
20:40:33 <rbergeron> also: i don't think that github wikis enable a discussion feature in the same way that wikipedia and other wiki software often does.
20:40:37 <chouse> every PR gets merged.
20:40:47 <chouse> as long as it is by the proposal's owner
20:41:03 <bcoca> rbergeron: lets check that out, cause discussion feature would make it really easy choice
20:41:30 <gregdek> #agreed we will create a separate repository for proposals
20:41:48 <chouse> i think we're over complicating it.
20:41:50 <gregdek> Is just "ansible/proposals" ok for everyone?
20:41:50 <rbergeron> bcoca: i just checked it out, it does not appear to be a thing or an option.
20:41:55 <rbergeron> chouse: yeah
20:42:02 <gregdek> chouse: maybe. :)
20:42:23 <gregdek> So to go back to my points earlier, if I may:
20:42:25 <chouse> sep repo good. one owner per proposal. one open issue per proposal.
20:42:27 <bcoca> :-(
20:42:36 <rbergeron> chouse: process sucks, but useful to provide something so people feel like things move and they ahve some framework to understand what to do and when
20:42:54 <rbergeron> too much process discourages people though :)
20:43:07 <rbergeron> gregdek: yes, go ahead
20:43:30 <bcoca> https://github.com/blog/774-git-powered-wikis-improved
20:43:32 <gregdek> * an artifact that is the proposal == the proposal file, submitted as a PR and immediately merged
20:43:40 <chouse> +1
20:43:50 <gregdek> * a way of tracking discussions of that artifact == a single issue, referenced in the proposal file
20:43:58 <chouse> +1
20:44:20 <gregdek> * a way of modifying the artifact == PRs to that file, merged or not at submitter's discretion and discussed in the issue
20:44:39 <gregdek> * a way of putting the artifact into buckets == maybe issue tags?
20:44:47 <chouse> +1
20:44:54 <gregdek> * a time/place to discuss == weekly proposal meeting.
20:45:02 <gregdek> That ticks all the boxes for me. Does it make sense?
20:45:11 <rbergeron> separate meeting just for proposals?
20:45:27 <rbergeron> Or incorporate into regular meeting until such time that we ahve so many excited umans that we need a separate meeting?
20:45:34 <gregdek> Maybe? I know we run the risk of getting weighed down by meetings.
20:45:44 <rbergeron> NO WAY REALLY
20:45:46 <gregdek> It could be that meetings are unnecessary for many/most proposals.
20:46:05 <chouse> maybe it's on the owner to bring it up and keep it moving.
20:46:16 <bcoca> i would leave it loose, consider the frequency and consensuse of opions on a proposal, hold meeting if stuck
20:46:17 <gregdek> Makes sense.
20:46:20 <rbergeron> disagree: meeting is the way to have a very clear rubber stamp and not have confusion about "does one person's okay mean everyone is okay?"
20:46:35 <gregdek> Well, hm.
20:46:38 <gregdek> Who gives the ok?
20:46:52 <rbergeron> when there is an #agreed in the meeting that it is approved.
20:47:03 <rbergeron> By whoemver is there. committers, whoever is present, I dont know.
20:47:05 <bcoca> by whom?
20:47:15 <gregdek> Not sure I agree. That means a meeting is required for every proposal, and I'm less sure that's useful.
20:47:17 <chouse> seems like the core team needs to weigh in
20:47:42 <gregdek> THe real goal of proposals is to give the "coder" a forum to figure out whether or not to proceed with an idea.
20:47:55 <bcoca> interview now, abadger1999 and i have to leave
20:48:09 <gregdek> Thus, it should be the coder who decides "that's enough info for now, and I will proceed or not based on feedback."
20:48:13 <gregdek> Right?
20:48:37 <gregdek> Because the core team can say "noope" and it doesn't necessarily prevent the coder from proceeding. It just means that it's not likely to get merged.
20:48:46 <bcoca> depends, if its something people won't accept ...
20:48:47 <gregdek> (thanks bcoca abadger1999!)
20:48:58 <bcoca> ah,yes, whatyousaid
20:49:13 <chouse> but that's the whole point. i want to know i'm building something will most likely get merged.
20:49:37 <gregdek> chouse: and you'll get that when people say "+1" in the issue, right? That should be sufficient.
20:50:00 <bcoca> well, if coder submits, gets -1 and pushes changes anyways ... he really was not target for proposal process
20:50:01 <chouse> if it's committers saying +1, then yes.
20:50:02 <gregdek> And this is important: we want consensus, not permission.
20:50:24 <gregdek> Not even committers agree 100% every time. Loose consensus will often have to be sufficient.
20:50:44 <gregdek> And I think it should be the coder who decides "ok I have enough positive feedback" or "nah I need to rethink"/
20:50:51 <bcoca> 50% of time if lucky
20:50:53 <gregdek> LOL
20:50:58 <chouse> sure. i'm just saying that it's important to get committer feedback, and it would be really nice to get core team feedback.
20:51:01 <abadger1999> (rbergeron tangent before I go: one thing I'd like to see added to the other suggested section of the proposal proposal is an alternatives section -- these were competing implementations/additional features for the spec that we discussed and discarded for these reasons.)
20:51:41 <gregdek> And if jimi-c says "+1" and bcoca says "-1", that's data that it's up to the coder to figure out. (but it's probably a "keep working on it").
20:51:58 <rbergeron> abadger1999: ack, i think, though wouldn't that possibly in the revision history of the proposal along with comments/
20:52:12 <rbergeron> okay either way, but just food for thought
20:52:13 <gregdek> Again: is this a forum for consensus or permission? Because they're different.
20:52:32 <chouse> consensus, i think
20:52:46 <rbergeron> i don't necessarily want it to be permission. but i want peopel to feel like ... if it's a process, then there shoudl be a resolution
20:52:58 <bcoca> proposal now reflect a possible good amount of work, if people dont want to wait for consensus ... they used their time unwisely
20:53:09 <abadger1999> rbergeron: not in one place likely -- git log shows what changed but not why.  multiple PRs are separate pages, discussion takes place in multiple comments or emails before finally arriving at a conclusion.
20:53:23 <rbergeron> i think they should have consensus enough to feel like they will move forward, and then it will be a cool thing on the official roadmap.
20:53:24 <chouse> i'm looking for some form of validation, i guess. the thing i'm working is valid and useful.
20:53:42 <dag-> gregdek: a forum for rationale ?
20:53:47 <rbergeron> ie: I'm a new proposal, i'm gaining consensus, and now i'm submitting it for approval as a feature on the roadmap.
20:53:51 <gregdek> Oh, dag!
20:53:54 <gregdek> Great! :)
20:54:00 <chouse> but, i'll get them from a healthy discussion on the issue.
20:54:21 <rbergeron> so it goes from new to "ready".
20:54:39 <gregdek> OK, dag, in your view: if you propose something, what does "acceptance" mean to you? Anything? An implicit agreement that your proposal will be merged?
20:54:55 * gregdek wander afk for a minute
20:55:03 <dag-> rbergeron: A proposal could come from someone not able to implement it himself too, I assume
20:55:34 <rbergeron> dag-: yeah, though that seems odd; that seems more like the diff between a "feature idea" and a "feature request"
20:55:47 <rbergeron> which bcoca pointed out to me earlier
20:55:51 <chouse> well, we're saying a proposer has to own it. so I guess they could outsource it.
20:56:03 <rbergeron> chouse: lol
20:56:22 <chouse> if only i had minions.
20:56:31 <rbergeron> dag-: though some combo (i have a feature proposal, i can implement part, and maybe others want to add on / do things of their own as well as part of it
20:56:36 <rbergeron> )
20:56:43 <dag-> gregdek: I think the most important feat is that someone needing something can coin if it's the right approach and if it would have a high chance of being merged
20:56:44 <rbergeron> but tring to not overcomplicate stuff at the moment
20:57:28 * gregdek back
20:57:28 <dag-> gregdek: and that by having a log of the discussion/rationale, contributors can get a feeling to what is (not) acceptable and why (not)
20:57:32 <rbergeron> dag-: exactly, but do they feel like it needs a rubber stamp that says, "we collectively like this idea, and if the code is good, it's likely to be merged"?
20:57:59 <dag-> rbergeron: that would help, and if it is timely, there's no frustration
20:58:37 <rbergeron> or do we expect they'll proceed without some sort of agreed guidance that appears as an official decision (caveat: if your code sucks, it won't get in)
20:58:40 <dag-> now PRs are in the backlog that people worked on months ago, we loose momentum and people don't know why
20:58:59 <rbergeron> dag-: right
20:59:08 <rbergeron> :(
20:59:10 <gregdek> That is, to some degree, a separate problem, but once we must also fix
20:59:10 <dag-> rbergeron: correct
20:59:26 <gregdek> we don't want to require people to submit full proposals for every PR
20:59:30 <rbergeron> greg is still grappling with the "permission vs consensus" thing
20:59:32 <dag-> if there are cases where there's no agreement, that's fine too, at least that's clear
20:59:33 <rbergeron> gregdek: exactly
20:59:54 <rbergeron> which is why guidance around "what shoudl be a proposal vs. just a regular pr" should probably exist
21:00:00 <gregdek> +1 to that
21:00:08 <rbergeron> and "ask if questions, happy to help guide"
21:00:24 <chouse> maybe it's new features and core module submissions?
21:00:28 <dag-> I think a proposal process makes most sense if the investment is high
21:00:33 <gregdek> it's kind of a slider. "simple = no proposal needed, complex or touches many pieces = proposal highly advised"
21:00:43 <rbergeron> the important thing is to be transparent and not get down on people if they ask
21:00:44 <dag-> because time spend on the wrong solution, is not just time lost, it's time not spend on the right solution
21:01:06 <rbergeron> and tell people they did a great proposal and bummer that you probably didn't need it, but this goes in our hall of fame for a proposal well done :)
21:01:12 <rbergeron> dag-: exactly
21:01:20 <chouse> LOL
21:01:23 <dag-> if the process causes more frustration than it takes away, we're doing it wrong
21:01:40 <chouse> do we have a hall of fame for that?
21:01:41 * gregdek wonders if rbergeron's proposal proposal will go into the proposal hall of fame
21:01:42 <rbergeron> release early release often... often starts with socializing the idea to make sure it's the right idea
21:01:45 <rbergeron> before writing the whole thing
21:01:54 <rbergeron> gregdek: it better
21:02:09 <rbergeron> gregdek: i demand gold stars and your explicit approval
21:02:11 <rbergeron> :)
21:02:27 <rbergeron> after i gain loose consensus
21:02:28 <rbergeron> of course
21:02:35 <rbergeron> am i even spelling that right?
21:02:44 <rbergeron> YES I AM
21:02:56 <rbergeron> okay, sorry... my mind is breaking down at this point
21:03:12 <gregdek> OK.
21:03:15 <rbergeron> dag-: i think you missed greg's proposal earlier
21:03:20 <gregdek> Lemme re-present my proposal:
21:03:26 <rbergeron> well, his "way forward" from this discussion
21:03:39 <rbergeron> "what do we actually need", we think
21:03:50 <dag-> rbergeron: I only read your commit, sorry
21:04:08 <gregdek> * an artifact that is the proposal == the proposal file, submitted as a PR and immediately merged
21:04:16 <gregdek> * a way of tracking discussions of that artifact == a single issue, referenced in the proposal file
21:04:23 <gregdek> * a way of modifying the artifact == PRs to that file, merged or not at submitter's discretion and discussed in the issue
21:04:32 <rbergeron> dag-: no worries, i pretty much meant for discussion to happen in the PR and not in separate places since that gets confusing
21:04:34 <gregdek> * a way of putting the artifact into buckets == maybe issue tags?
21:04:48 <rbergeron> but i think some clarity was being requested here in our community working group meetin' time
21:04:51 <gregdek> * a time/place to discuss when we get stuck == weekly proposal meeting
21:05:00 <gregdek> And then what we were discussing:
21:05:08 <rbergeron> dag-: he's copypasting though so hooray, time machine
21:05:21 <gregdek> * A completed proposal == ...when the proposer makes a decision to proceed (or not)?
21:05:56 <gregdek> dag: would that work for you?
21:06:11 <gregdek> (And all of this in a separate proposals repository)
21:06:19 <gregdek> (With its own issue queue)
21:06:45 <dag-> gregdek: It works for me, don't know if it works for the community (that's your area of expertise ;-))
21:06:54 <chouse> i like it.
21:06:57 <gregdek> well, you are the community, buddy. :)
21:07:05 <dag-> ah, a separate repository, I wanted to ask it
21:07:12 <gregdek> So if it works for you, IT WORKS FOR THE COMMUNITY! *applause*
21:07:32 <dag-> *blush*
21:07:36 <rbergeron> :)
21:07:40 <gregdek> ok.
21:07:56 * chouse does a happy dance
21:08:04 <gregdek> I know abadger1999 and bcoca are still afk, but I think we can start from here.
21:08:09 <gregdek> I guess we have actions!
21:08:23 <gregdek> #action create the new ansible/proposals repo
21:08:41 <gregdek> #action relocate current proposals into new repo
21:09:34 <gregdek> #action update our proposal proposal with the details from this proposal
21:09:54 <rbergeron> I think so.
21:10:00 <rbergeron> i hope so
21:10:02 <rbergeron> zomg
21:10:30 <gregdek> I think we're done, right?
21:10:37 <rbergeron> dag-: thanks for coming :)
21:10:37 <gregdek> I feel pretty done.
21:10:47 <chouse> i'm done.
21:10:48 <rbergeron> and chouse for poking at us :)
21:10:48 <dag-> gregdek: How do we know who has authority (ie. typical problem with mailinglists, people voice opinions, but people have no clue what's the authoritative opinion)
21:10:49 <gregdek> Thanks dag. Very helpful to have your input.
21:11:11 <rbergeron> dag-: i have explored this a bit.
21:11:16 <gregdek> dag: I'm not sure we want to have "authority". I think "consensus" is the goal.
21:11:32 <gregdek> We will have more committers soon, and they are likely to have diverging opinions.
21:11:57 <rbergeron> well, as the group grows, it's more likely that there are more possibilities for different opinions.
21:12:10 <rbergeron> not "the new committers will have different opinions"
21:12:11 <dag-> maybe I am using the wrong wording, but everyone can voice opinion ? at some point someone may have to take a decision
21:12:21 <dag-> rbergeron: indeed
21:13:07 <dag-> I'd assume commiters have a "real" vote, whereas others have opinions ?
21:13:11 <dag-> or something like that
21:13:57 <chouse> so did we lose the idea of 'approved'?
21:16:45 <rbergeron> sorry, tending to #ansible for a moment
21:17:41 <rbergeron> dag-: I'd mostly like to see that most things are just going to obviously be approved as "likely to be accepted" because the appropriate consensus was built before the meeting.
21:19:17 <chouse> that seems reasonable
21:19:51 <dag-> rbergeron: ok, I'll see how things work first in practice
21:20:02 <rbergeron> but people still feel like they ahve something actually showing that "likely to e accepted"
21:20:13 <rbergeron> dag-: that's part of the plan :)
21:20:23 <rbergeron> test the proposal process with the process proposal!
21:22:45 <rbergeron> #action rbergeron to incorporate a lot of stuff along with pointer to this log and ... move forward, + greg's above action items
21:22:54 <rbergeron> which i guess already stated that i'd do that.
21:23:21 <dag-> rbergeron: thanks for putting the time into this (gregdek likewise)
21:24:53 <rbergeron> okay: I'm going to wrap up the meeting
21:25:22 <rbergeron> dag-: happy to, I was doing something else and discovered i did a bunch of writing incorrectly because i wasn't aware that there was a new thing about proposals because i missed it :)
21:25:26 <rbergeron> and it's not documented
21:25:37 <rbergeron> and that kind of thing drives me NUTTTTTTTS
21:26:06 <rbergeron> along with just ... having been in the position of not knowing where something i want to do sort of stands in the pipeline
21:26:13 <rbergeron> it can be frustrating and i like to see that undone
21:26:14 <rbergeron> so.
21:26:16 <rbergeron> voila!
21:26:18 <rbergeron> and with that:
21:26:26 <rbergeron> #action rbergeron to send out logs after meeting
21:26:41 <rbergeron> and i'm gonna close up themeeting, unless anyone else has any feedback
21:26:44 <rbergeron> #topic Open Floor
21:26:49 <rbergeron> (on other topics)
21:27:00 <rbergeron> Y'all have like 1 minute until i strap my jetpack on and zoom out of this meeting :)
21:29:58 <rbergeron> okay, thanks for coming and chatting :)
21:30:05 <rbergeron> meetings are awesome on irc :)
21:30:09 <rbergeron> #endmeeting