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