20:12:18 <gundalow> #startmeeting AnsibleFest Austin: Contributors Summit - Contributor Experience
20:12:18 <zodbot> Meeting started Mon Oct  1 20:12:18 2018 UTC.
20:12:18 <zodbot> This meeting is logged and archived in a public location.
20:12:18 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:12:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:12:18 <zodbot> The meeting name has been set to 'ansiblefest_austin:_contributors_summit_-_contributor_experience'
20:12:29 <gundalow> #info https://etherpad.openstack.org/p/ansible-community-experience
20:12:36 <gundalow> #chair bcoca felixfontein mattclay
20:12:36 <zodbot> Current chairs: bcoca felixfontein gundalow mattclay
20:14:40 <misc> damn, I was on the wrong meeting, the etherpad still list gdk bjn :/
20:16:19 <felixfontein> misc: you didn't miss much so far
20:18:12 <gundalow> misc: Hey
20:18:35 <misc> yep, I am
20:19:10 <gundalow> #info https://github.com/orgs/ansible/projects/2
20:20:38 <gundalow> #info New Contributors https://github.com/ansible/community/issues/353
20:26:52 <felixfontein> I think that's a pretty good thing, to have the bot issuing more infos
20:27:08 <gundalow> What more info should it list
20:27:48 <felixfontein> I think the stuff you listed is already very good. I'm not sure much more is needed
20:28:22 <gundalow> #info Identify common issues, feed those into Bot, CI etc
20:28:27 <gundalow> #info Speak to the people
20:28:30 <felixfontein> something I noticed: PRs for new plugins (at least lookup plugins) do not get anything yet (except some labels)
20:29:36 <felixfontein> eventually someone human removes the needs_triage label :)
20:29:43 <gundalow> #info Add the human touch - Personally great people
20:30:43 <bcoca> i am not a bot!
20:31:00 <misc> the b is not for bcoca ?
20:31:04 <misc> mhh
20:31:10 <misc> the b is not for bot ?
20:31:16 <felixfontein> lol
20:31:24 <bcoca> its for borg as in cyborg
20:31:39 <gundalow> #info Docs team are meeting weekly to review docs PRs. They are also aiming to give a human response and a) request feedback b) close c) fix d) fix+merge
20:31:56 <gundalow> #info Bot is good for rapid turn around, not for the human touch
20:31:58 <bcoca> e) point and laugh at bcoca mispellings
20:33:51 <gundalow> #action gundalow to follow up with David@cisco about why merging didn't work
20:35:05 <gundalow> #info take advantage of GitHub's notifications of CONTRIBUTOR.md linking for new_contributors
20:36:32 <gundalow> #info Add very basic workflow (with links to other docs) into `CONTRIBUTOR.md` so people will be notified via GitHub UI
20:37:43 <felixfontein> changelog fragment, test, ...
20:38:56 <felixfontein> no automerge is fine for me, as long as shipit'ed PRs are processed "fast enough" manually. currently it seems one has to bug someone on IRC to get it merged in reasonable time
20:40:51 <felixfontein> +1
20:41:19 <gundalow> #agreed adding a changelog shouldn't block automerge
20:42:42 <felixfontein> some general guidelines for changelog fragments would be nice :)
20:44:15 <gundalow> felixfontein: yup, as you may have noticed we haven't as a Core Team haven't agreed on what the rules are
20:44:34 <felixfontein> everything which affects lib/ansible/modules and lib/ansible/module_utils should probably get one
20:44:53 <felixfontein> gundalow: yes, I noticed that several times already. that's why I keep repeating that ;)
20:44:57 <gundalow> :)
20:46:11 <felixfontein> I would say that user-affecting changes (i.e. code which is executed by the user, and maybe also docs read by the user) should have a changelog fragment. that usually excludes tests.
20:46:45 <misc> maybe we should automerge only if there is new test added
20:47:05 <misc> (cause we want more tests, and so people should have a incentive for that)
20:47:33 <felixfontein> misc: I would only require that if there are already tests... adding the first test can be quite some work
20:47:44 <felixfontein> (and having to do that to get a simple bugfix merged is pretty annoying)
20:48:15 <abadger1999> lib/ansible/release.py
20:48:18 <abadger1999> gundalow: ^
20:48:19 <misc> felixfontein: it wouldn't just be automerged
20:48:28 <abadger1999> bin/ansible-test
20:48:38 <gundalow> #info PRs that affect lib/ bin/ contrib/ (but not bin/ansible-test lib/ansible/release.py) MUST have changelog fragment for stable-x.y PRs
20:48:50 <abadger1999> +1
20:48:55 <misc> the alternative is to give a bigger cake when you have tests in your PR
20:49:11 <bcoca> no cake, i need to loose weight
20:49:18 <felixfontein> misc: bigger cake sounds better!
20:49:20 <gundalow> eat cake, lose cake
20:49:26 <felixfontein> vcake
20:49:36 <misc> bcocake
20:49:43 <felixfontein> purely virtual, no weight included
20:50:32 <abadger1999> mattclay is saying that we should include for devel, not just for stable-x.y.
20:50:36 <bcoca> lies, bits use electrons, electrons have mass .. so there IS weight
20:50:45 <abadger1999> (and I agree with that)
20:51:12 <bcoca> i would not require for things like typo fixes
20:51:32 <felixfontein> what about new module PRs? they are not supposed to have a changelog fragment so far
20:52:00 <gundalow> I have no idea what is meant to happen for new modules wrt Changelogs
20:52:04 <bcoca> we already list those in clog anyways, but im fine with still requriing one
20:52:41 <felixfontein> bcoca: but that would justbe manual repetition of info
20:52:56 <bcoca> we never do that!
20:55:52 <felixfontein> +1
20:58:11 <misc> I wonder if we can detect that a new parameter have been added to a module by inspecting the inline doc, and request a changelog entry
20:58:21 <misc> and the same go for new module
20:58:46 <felixfontein> new modules are already handled automatically I think
20:59:14 <gundalow> felixfontein: ah, OK
21:00:11 <felixfontein> https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst#new-modules-2
21:01:16 <bcoca> we have a script, but i believe it still requires manual running
21:02:49 <gundalow> #info Agree (via dev_guide) when we need `fragments`
21:04:51 <gundalow> #info Question: How do we increase testing
21:05:04 <gundalow> #info Question: How do we increase people looking at/testing PRs
21:05:48 <jlk> hey all. I forgot to pay attention in here, but if there was a set of things "It would be nice if GitHub did..." or "it really sucks that GitHub does / doesn't do...", please send them my way
21:05:51 <misc> +1 for the idea being proposed
21:06:12 <misc> jlk: so, it would be nice to be able to exclude a label on the search
21:06:27 <gundalow> misc: `-label:module`
21:06:37 <gundalow> that?
21:06:52 <misc> gundalow: mhh, ok so change my request to "make it easy to find"
21:07:02 <misc> cause I am kinda sure I did tested that :/
21:07:27 <misc> but maybe I forgot the "label"
21:07:30 <abadger1999> 1436 commits from branchinsh stable-2.6 to 2.6.0 release
21:07:37 <abadger1999> acozine: ^
21:08:00 <felixfontein> wow
21:09:22 <abadger1999> jlk: far afield but: github flavoured markdown that generates a table of contents (for wiki usage)
21:09:57 <gundalow> #info "Topic of the week" - How to get people together for one purpose
21:10:09 <bcoca> beer
21:12:05 <misc> that's for more than 1 week
21:15:29 <gundalow> #info reducing back-and-forth needs to be done
21:16:15 <gundalow> #info What other working groups do we need - Look at PRs per directory.
21:19:37 <gundalow> #info Use GitHub issues to notify maintainers to see if they would be interested in setting up a Working Group
21:21:17 <gundalow> #info review maintainers guide
21:21:17 <abadger1999> #info The Fedora Project has/had similar problems with reviewing new packages.  There are three former Fedora Project Leaders here, at ansiblefest that you could pick the brains of:  Matt  Miller, robyn, and gregdek
21:22:08 <felixfontein> no, not really
21:22:21 <misc> nope
21:22:34 <abadger1999> (clarification matt miller is the present fedora project leader, not former)
21:23:17 <gundalow> abadger1999: https://github.com/orgs/ansible/projects/2
21:25:11 <abadger1999> #info org level github project to make visible the Contributor Experience action items https://github.com/orgs/ansible/projects/2
21:25:28 <abadger1999> gundalow: oh, I'm not a #chair
21:25:42 <gundalow> #chair abadger1999
21:25:42 <zodbot> Current chairs: abadger1999 bcoca felixfontein gundalow mattclay
21:25:47 <abadger1999> #info The Fedora Project has/had similar problems with reviewing new packages.  There are three former Fedora Project Leaders here, at ansiblefest that you could pick the brains of:  Matt  Miller, robyn, and gregdek
21:25:58 <abadger1999> #info org level github project to make visible the Contributor Experience action items https://github.com/orgs/ansible/projects/2
21:26:32 <gundalow> #info How did "Active Community Members" find out/get involved. How can we encuragethat
21:27:27 * misc got involved because he found too much bugs
21:27:38 <felixfontein> that there is an IRC channel was pretty obvious for me, it is mentioned a lot
21:27:46 <gundalow> misc: well there are lots of bugs, so we should have many more people then :)
21:27:58 <gundalow> #info how do we define "active" in the above
21:28:07 <felixfontein> not everyone is good at fixing bugs... or even just reporting
21:28:15 <bcoca> documenting
21:28:21 <bcoca> testing
21:28:25 <bcoca> many ways to contribute
21:28:40 <bcoca> even just 'confirming' a bug or a fix
21:29:18 <gundalow> #info Post-Contributors Blog post should also make it clear that we aren't just talking about Python programmers - Link to acozine's talk
21:29:54 <gundalow> #info Post-Contributors Blog post - Also detail what type of participation we are looking for
21:32:28 <felixfontein> yes, why delay an easy fix if it can be done easily
21:33:00 <abadger1999> I think it makes sense if we're actively working to onboard new contributors.
21:33:13 <misc> depend how critical is the fix too
21:33:56 <bcoca> i have not seen an easy fix in a while
21:33:56 <felixfontein> definitely
21:34:07 <bcoca> but i barely look at modules
21:34:11 <bcoca> anymore
21:34:21 <misc> but I guess we could say that a easyfix stay there for 1 month, then anyone could take it, assuming there is enough new easyfix ?
21:35:02 <felixfontein> if it stays there for one month, it misses at least one release
21:35:18 <felixfontein> which I think is not really nice for bugfixes
21:35:22 <bcoca> easy for whom? some of the things we tagged as such in past were left there w/o anyone picking them up, others were resolved same day
21:35:23 <felixfontein> (for features that's ok, though)
21:35:32 <gundalow> #info Create issue" WG - todo list" 1) Docs 2) PRs without needs_info/needs_revision 3) Needs test
21:35:37 <abadger1999> as in, some one can goes out and fixes five easyfixes.  Do we (1) quickly review their fixes, give them feedback, and then merge their stuff?  (2) Do we then start pushing harder bugs at them? (3) Do we reach out to them on IRC? (4) Do we start asking them for their opinions on code that they've gotten experience with?  (5) Is there a path for them to become a committer? (6) Is there a path for mentoring them and working to
21:35:38 <abadger1999> improve their skills?
21:35:48 <misc> bcoca: yup, hence making sure the label do expire I guess
21:40:14 <gundalow> #info Badges: Mozilla & Fedora - Ask Matthew Miller if they've helped or not. What are the real rewards  (recognition, merge rights, etc)
21:45:45 <gundalow> #info Lessons learnt from Network Documentation t-shirt game - Multiple example PRs on same file resulted in continual merge conflicts. Had a few people that tried to "game" the system (just copy-paste). Next time: Would timebound it from the start. Add initial limits for responses from PR authors. More general ensure every module EXAMPLE has a `- name: ` set
21:49:02 <gundalow> #info Look at https://openbadges.org/ and https://badges.fedoraproject.org/
21:51:24 <felixfontein> thanks for moderating!
21:51:25 <misc> no problem
21:51:36 <misc> gundalow: so, on the issue of people gaming the system, maybe it should be done in such a way that gaming the system is in the system ?
21:51:56 <felixfontein> :D
21:52:40 <gundalow> #info Badges/points for doing X each week. Number of weeks X was done. Number of continuous weeks where X was don e
21:53:05 <misc> that's what duolingo do, and so I am now learning german to game the system
21:53:06 <bcoca> merge points
21:53:38 <gundalow> #info what are the rewards
21:54:07 <misc> bcoca: merge coin, that you can trade for a review
21:54:22 <felixfontein> enjoy the party and ansiblefest!
21:54:32 <felixfontein> (while europe goes to sleep ;) )
21:54:40 <acozine> we'll drink a beer for you europeans
21:54:55 <felixfontein> cheers! bye!
21:55:10 <abadger1999> https://www.redhat.com/archives/fedora-devel-list/2004-May/msg00104.html
21:56:43 <gundalow> #endmeeting