18:00:13 <felixfontein> #startmeeting Ansible Community Meeting
18:00:13 <zodbot> Meeting started Wed Jun 30 18:00:13 2021 UTC.
18:00:13 <zodbot> This meeting is logged and archived in a public location.
18:00:13 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:13 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:13 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:13 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:17 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:17 <andersson007_> o/
18:00:28 <felixfontein> #chair andersson007_
18:00:28 <zodbot> Current chairs: andersson007_ felixfontein
18:00:35 <briantist> o/
18:00:49 <felixfontein> #chair briantist
18:00:49 <zodbot> Current chairs: andersson007_ briantist felixfontein
18:01:00 <samccann> sorry in a training session today
18:01:18 <cidrblock> hey all
18:01:30 <cyberpear> o/
18:01:32 <jillr> will be late, another meeting is running over
18:01:40 * cybette will be here in 5 min
18:01:56 <felixfontein> #chair cidrblock cyberpear jillr cybette
18:01:56 <zodbot> Current chairs: andersson007_ briantist cidrblock cyberpear cybette felixfontein jillr
18:02:37 <felixfontein> #topic Updates
18:02:37 <felixfontein> #info Ansible 4.2.0 has been released
18:02:37 <felixfontein> #info Devel docs now pull latest collection releases available for all collections that will be included in the next Ansible major version, not latest releases included in Ansible
18:02:41 <felixfontein> #info Reminder: don't forget to vote on names in https://github.com/ansible-community/community-topics/issues/26
18:04:48 <briantist> just looked, I'll abstain from names, I have no real opinion
18:05:13 * gundalow waves
18:05:53 <felixfontein> #chair gundalow
18:05:53 <zodbot> Current chairs: andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr
18:07:39 <felixfontein> looks like there aren't that many people around today
18:08:19 <gundalow> David, Deric, Greg, and Ompragash are off today
18:08:41 <jillr> I'm present now, sorry about that
18:08:42 <andersson007_> Sandra also
18:09:10 <gundalow> cidrblock: have you and Ganesh  and webknjaz looked at https://github.com/ansible-community/community-topics/issues/26
18:09:51 <felixfontein> are Toshio and Alicia around today?
18:10:09 <gundalow> abadger1999: You around for meeting?
18:10:23 <gundalow> I know he was deep in some Docs stuff earlier
18:11:10 <cidrblock> gundalow, not in detail.  The devtools team is just building it's charter and plans, early days still
18:11:11 <aminvakil> o/
18:11:52 <felixfontein> #chair aminvakil
18:11:52 <zodbot> Current chairs: aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr
18:12:28 <felixfontein> #topic What should we do with unresponsive module maintainers?
18:12:28 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/27
18:12:32 <felixfontein> let's start with this one then
18:13:14 <aminvakil> ah, i should've prepared something more definite for this, sorry
18:13:29 <gundalow> aminvakil: I think you've made a good starting point
18:13:41 <felixfontein> right now we have quite a few maintainers listed in .github/BOTMETA.yml who are not responding
18:14:06 <gundalow> What's do people feel that potential advantages of removing unresponsive maintainers could be?
18:14:12 <felixfontein> so we need to clean up that list. the big question is: how?
18:14:13 <andersson007_> is this only to clean up BOTMETA?
18:14:22 <felixfontein> andersson007_: what else? :)
18:14:26 <aminvakil> yeah, we faced another issue today in c.g. for snap module, there was a PR which got merged very long time and it was just broken, if one of maintainers could just test this we wouldn't face this today
18:14:36 <andersson007_> felixfontein: I don't know:)
18:14:58 <aminvakil> gundalow: as i've said honestly i don't know what is the value in this (removing maintainers from .github/BOTMETA.yml really
18:15:07 <gundalow> removing unresponsitive maintainers wouldn't help that snap example
18:15:11 <abadger1999> Sorry I'm late
18:15:13 <jillr> gundalow: clarity around if a module even has any maintainers, who contributors might expect to be able to contact for help, generally making PRs less noisy
18:15:31 <briantist> I like the suggestion laid out by felixfontein . For andersson's q: `Also if there are, say, 5 folks listed and in a month after constant pinging them all only one responded, should we remove the other 4 at once?`, I think if the suggested procedure is followed for all, then some will or won't respond after all that. The ones that don't, I see no problem removing them all at once (at the end of the process)
18:15:43 <felixfontein> gundalow: right now for a new issue/PR a lot of people get pinged, but most of them never react - which can be annoying to contributors if the people supposed to review never give any reaction
18:15:53 <felixfontein> #chair abadger1999
18:15:53 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr
18:17:16 <felixfontein> briantist: I agree
18:17:19 <felixfontein> abadger1999: welcome :)
18:17:37 <cyberpear> sounds reasonable to me
18:17:40 <andersson007_> it can be annoying but in case of emergency somebody can ping a maintainer directly via email
18:17:44 <andersson007_> if specified
18:17:51 <aminvakil> could that be a motivation for new contributors to become maintainer of a module if there isn't any? (if we have removed unresponsive maintainers and as andersson007_ has stated in issue it's more clear that a module is orphaned)
18:18:03 <abadger1999> <nod>. It also gives us a file we can consult to see if a module should be declared as orphaned and in bed of new maintainers
18:18:10 <felixfontein> andersson007_: if maintainers never react (for years), I don't think they want to be pinged by email either
18:18:15 <abadger1999> S/bed/need/
18:18:21 <andersson007_> felixfontein: also true
18:18:27 <andersson007_> but sometimes it works
18:18:55 <felixfontein> abadger1999: yep (also the orphaning process is another topic for this or a later meeting ;) )
18:19:14 <jillr> I see sometimes after the bot pings someone a contributor will keep pinging that user again and again for reviews; that's a bad experience for the contributor and may stop them from looking for other avenues of requesting review
18:19:23 <felixfontein> andersson007_: true. I guess it makes sense to ping them by email to determine whether they still want to be maintainers. if they don't respond at all, it's time to remove them
18:19:33 <gundalow> jillr: hum, that's a fair point that I hadn't considered
18:19:41 <jillr> taking those unrepsonsive names out would alleviate some of that, maybe
18:19:42 <andersson007_> felixfontein: agreed
18:19:46 <cidrblock> Has there ever been a conversation about setting the state of a plugin?  Which could help contributors identify where it is in it's lifecycle?  (actively maintained, abandoned, up for adoption, pending removal)
18:20:08 <cybette> cyb-clock chimes: 20 minutes into meeting, 8 min on topic of unresponsive maintainers
18:20:15 <andersson007_> felixfontein: +1 to add pinging directly via email to the procedure
18:20:24 <aminvakil> cidrblock: putting modules in each of those states is every hard
18:20:30 <aminvakil> s/every/very
18:20:32 <felixfontein> cidrblock: that's another topic on the agenda :)
18:20:40 <cidrblock> woohoo
18:20:53 <felixfontein> it's hard to determine that status when not knowing whether there are active maintainers though
18:21:11 <jillr> andersson007_: sorry, what's the case for pinging via email?  do you mean having the bot ping for reviews?
18:21:25 <cidrblock> yeah, the maintainer activity would be one piece of the criteria
18:21:28 <briantist> jillr: totally agree, it looks real bad when someone sees real named pinged and they don't respond, I think it also looks to other active members of the collection that they don't have to step in and so it can exacerbate the issue of the contributor getting no response
18:22:11 <andersson007_> jillr: i mean before removing maintainers we could ask them via email if they are still interested
18:22:24 <jillr> andersson007_: oh ok, that makes sense!
18:22:49 <felixfontein> I guess we can first ping on github, and if there's no reply in say a month, send them an email. if there's no reply a couple of months later, remove them from the maintainer list
18:23:03 <andersson007_> maybe all emails by the bot go to spam or something
18:23:22 <jillr> or people's github notices are just a dumpster fire  :)
18:23:36 <aminvakil> fwiw aur (arch user repository) has this process too, everyone can submit a orphan request for a package, but they MUST email maintainer before and explain the problem that they are not reacting to, and if they don't respond to email, they can submit an orphan request
18:23:38 <cidrblock> bc I don't know, how to know who to ping?
18:23:40 <andersson007_> felixfontein: I think we can remove them quicker after a personal email
18:23:43 <abadger1999> jillr: +1
18:24:04 <aminvakil> andersson007_: +1
18:24:08 <gundalow> We generally don't have anyones email
18:24:08 <felixfontein> andersson007_: I'd still wait for a month. sometimes people are on a long vacation
18:24:20 <briantist> andersson007_: +1, no more than an extra month
18:24:22 <abadger1999> I know that's the case for me.  I often miss the github emal where someone directly asked for my input with all the other stuff I was autosubscribed to.
18:24:32 <andersson007_> felixfontein: a month is fine
18:25:03 <felixfontein> need_info is also 2-3 months, I don't think we should be quicker than that
18:25:10 <gundalow> felixfontein: agreed
18:25:11 <jillr> gundalow: git log
18:25:41 <andersson007_> 2-3 months is not good for PR authors
18:25:58 <andersson007_> it's enough to get frustrated
18:26:20 <gundalow> Well, removing an unresponsive maintainer isn't going to speed that up
18:26:21 <aminvakil> gundalow: if they don't respond with github ping, and they don't respond to their mail address which has been stated in git log, they can't help maintaining module anyway
18:26:41 <briantist> andersson007_: I definitely agree, that time frame sucks a lot. But I suppose it's something of a separate issue (removing maintainer vs. someone else responding in place while the removal process finishes)
18:27:24 <felixfontein> aminvakil: well, they can be temporarily away or busy, and 2-3 months later they could be back and respond immediately
18:27:41 <jillr> felixfontein: we can always add them back
18:27:44 <aminvakil> i guess they can be added as maintainer again
18:27:47 <felixfontein> so giving them some time when trying to remove them is fair IMO
18:27:47 <andersson007_> are we talking about removal PRs?
18:27:53 <gundalow> For clarification, BOTMETA is only used by repos running the Bot, s.general, c.network, aws, vmware (I think)
18:28:00 <felixfontein> andersson007_: I'm talking about removal PRs
18:28:01 <briantist> I wonder if even just a note to the contributor of a PR getting no response to say that others are actively reaching out to the maintainer(s) would go a long way
18:29:10 <cybette> briantist:  +1 for showing that someone is doing something
18:29:30 <andersson007_> ok, maybe: 1) create a PR 2) in 2 month, ping folks directly via email 3) in a month remove them
18:29:31 <andersson007_> ?
18:29:50 <andersson007_> or 2) in 1 month
18:29:56 <felixfontein> andersson007_: I would ping them after ~one month, and remove them ~2 months after that if there's no reaction
18:30:07 <aminvakil> 1 month is enough imo
18:30:14 <abadger1999> Or maybe a way to add maintainers more quickly.
18:30:21 <felixfontein> so they have ~three months in total, and they have both a GH ping and an email ping
18:30:41 <aminvakil> because they have been already unresponsive till it reaches a point that someone opens a PR removing them from .github/BOTMETA.yml
18:30:43 <jillr> When someone leaves the note in the PR about trying to contact the maintainer, we should also drop the PR link in irc and ask for reviewers
18:30:43 <abadger1999> ie, if we've started the process and are into the first month of waiting, can we ask the PR submitters if they'd want to become a maintainer?
18:30:56 <andersson007_> if a email is hidden?
18:31:04 <briantist> aminvakil: +1, I also lean toward shorter removal if they can be added back practically instantly
18:31:08 <andersson007_> abadger1999: we do it
18:31:18 <andersson007_> regularly
18:31:22 <cidrblock> Any value is having an issue in the repo as well?  Would most issue contributors know to look at a BOTMETA PR to know the repo may not be actively maintained?
18:31:36 <felixfontein> abadger1999: I'm not sure if I want to make random people maintainers when all I see from them is one PR that hasn't been reviewed yet
18:31:59 <felixfontein> (or only got a basic/general review by other community members who don't really know the thing that the module manages)
18:32:05 <abadger1999> felixfontein: <nod> But the alternative is no one caring about the software.
18:32:21 <cidrblock> is = in
18:32:40 <abadger1999> We could also remove plugins from the collection and tell people to maintain them in their own collections, I suppose.  But that's even slower.
18:33:12 <jillr> Maybe it's so much, "do you want to maintain this" and more, "we're always looking for community maintainers, if that interests you please get involved / ask us how to get move invovled"
18:33:24 <andersson007_> felixfontein: i think that's better than nothing and the second shipit is needed anyway
18:33:26 <jillr> invite them to become more active without just handing them the keys to merge PRs
18:33:34 <andersson007_> can be like additional motivation
18:34:16 <briantist> jillr: yeah that's how it happened for me. Initial maintainer of a plugin in c.g didn't give me any additional permissions, just meant I got pinged automatically 😅
18:34:22 <andersson007_> + people will know if their changes crash something
18:34:26 <andersson007_> bot will notify them
18:35:03 <jillr> offer also valid for more maintainers in community.aws, while we're talking about it  ;)
18:36:38 <andersson007_> let's maybe decide something on the topic:)
18:36:40 <sivel> An unresponsive maintainer for an individual PR or issue, doesn't mean that the plugin is non-functional, or that the maintainer is generally unresponsive. Not all people care about the same things, so they may just be ignoring specific issues/PRs they aren't interested in
18:37:15 <sivel> Would need to be some criteria, that applies more broadly than ignoring 1 or 2 issues/PRs
18:37:18 <sivel> my 2c
18:38:10 <cyberpear> right. I might be maintaining 2 modules that my work allows me to do on company time, but then 4 more that are on "hobby time"... the latter might get much longer response times
18:38:13 <andersson007_> in this case they should respond to a removal PR:)
18:38:16 <sivel> I ignore things all the time while simultaneously being responsive for things that stimulate me
18:38:47 <jillr> I had been reading this as being around folks who are consistently unresponsive, not just on a single PR
18:39:08 <briantist> ^ yes this
18:39:55 <felixfontein> sivel: I'd only consider maintainers who haven't reacted in say a year to any issue/PR
18:39:55 <andersson007_> it's hard to track
18:39:57 <jillr> I dont know what the metric for that would be offhand. 10 PRs?  10 months?  (random numbers for example)
18:40:09 <felixfontein> assuming there have been several ones
18:40:23 <felixfontein> if there was no issue or PR, everything's fine ;)
18:40:25 <aminvakil> jillr: some modules do not get that many issues/PRs at all
18:40:33 <sivel> yeah, I suppose my intention was to outline what metric defines a unresponsive maintainer.
18:40:48 <sivel> and that an unresponsive maintainer doesn't mean that the plugin is non-functional
18:41:04 <cybette> cyb-clock chimes: 40 minutes into meeting, 28 min on topic of unresponsive maintainers
18:41:41 <aminvakil> also there are lots of issue/PRs which repository maintainers review, test, change and merge themselves without maintainer's help and no one notices if module maintainers have just read and was fine with everything or they don't care / they don't see ...
18:42:44 <aminvakil> there aren't lots of issues/PRs which reach to a level that maintainers specifically mention module maintainer and ask for their input
18:43:29 <aminvakil> (i'm mostly talking about c.g., this may differ on other repositories)
18:43:33 <cidrblock> find myself wondering if this should be gone at from the other direction, how do we maintain a healthy code base, figure out the unresponsive maintainer issue only when it is causing an issue
18:43:34 <briantist> sivel: should maybe each collection/repository should define their own metrics for what defines unresponsive?
18:43:52 <briantist> cidrblock: yeah, well said
18:44:06 <gundalow> I'm not sure if we are getting anywhere. Would it be useful to define the `health metric` first/
18:44:08 <gundalow> ?
18:44:09 <cidrblock> (because even a responsive maintainer == healthy code)
18:44:45 <gundalow> maintainer responsiveness doesn't have to have anything to do with health of code
18:45:03 <felixfontein> :)
18:45:15 <abadger1999> There are times, though, when you might get something like a security issue and if you don't have someone with domain specific knowledge, it's too late to fix that lack.
18:45:23 <andersson007_> I'd suggest first deciding something on "should we remove unresponsive maintainers from BOTMETA?". Then we can discuss the metric of unresponsiveness
18:45:37 <gundalow> Poll: should we remove unresponsive maintainers from BOTMETA?
18:45:38 <abadger1999> andersson007_: +1, let's move the chains
18:45:40 <abadger1999> +1
18:45:46 <tadeboro> Sorry for being late. I feel asleep after my series of late afternoon meeting calls.
18:45:49 <jillr> +1
18:45:53 <andersson007_> +1
18:46:05 <aminvakil> +1
18:46:08 <briantist> +1
18:46:12 <cidrblock> healthy code base + community  (healthy code base meaning all aspects of the community and community package, not just the actual python line... )
18:46:12 <gundalow> -1 No, as there are many reasons a maintainer may not be responsive. They may still respond to critical issues
18:47:15 <felixfontein> +1 assuming unresponsive means they haven't responded for a long time
18:47:20 <felixfontein> #chair tadeboro
18:47:20 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr tadeboro
18:47:22 <cybette> 9
18:47:28 <cybette> oops, I mean 0
18:47:29 <cidrblock> -1 the def of unresponsive still not clear enough, and unless unresponsiveness is causing some other issue
18:47:49 <cyberpear> 0
18:48:28 <abadger1999> cidrblock: Defining unresponsive would be a followup vote... I think we're trying to define whether we're even wanting to remove unresponsive maintainers or not.
18:48:39 <abadger1999> (which might be your second point)
18:49:00 <tadeboro> +1 if we define what unresponsive means.
18:49:40 <tadeboro> From my experience, people who do not pull along ofter become a weight that slows everything down and makes making progress really hard.
18:49:51 <cyberpear> I think it should be much lower friction to add a new maintainer than remove a slow-to-respond one; one shouldn't depend on the other, at least not strongly
18:50:46 <cidrblock> I can't vote on whether we should remove unresponsive maintainers w/o knowing what unresponsive means........... +1 to define it
18:50:50 <felixfontein> cyberpear: yes, definitely
18:51:48 <abadger1999> It sounds like, from the votes so far, we do support removing unresponsive maintainers.
18:51:52 <felixfontein> #agreed we should remove unresponsive maintainers (to be defined) from BOTMETA
18:51:57 <briantist> the reason I'm +1 without a definition is that I think the definition can (maybe "should") be fluid
18:52:02 <cidrblock> eg, if unresponsive means 10000 open PRs and 10000 issues, +1, if it's 1 PR for 3 months, and 0 issues, -1
18:52:28 <felixfontein> briantist: I agree, I don't want that decision to be made by a bot, there should always be some human judgement involved :)
18:52:37 <briantist> (and also that it's not that big of a deal to add someone back)
18:52:51 <briantist> also agreed, it shouldn't be a bot
18:53:02 <cidrblock> I agree there is a point in time to remove a maintainer, IMO, time should be spent identifying that criteria
18:53:40 <sivel> and more importatnly, other than removing the maintainer, what do we really want to achieve after we have identified an unresponsive maintainer
18:53:55 <sivel> removing the maintainer doesn't really help anything
18:54:03 <felixfontein> I think it depends on the amount of issues/PRs that the person has been pinged for (also where they have been pinged as a namespace maintainer for new module PRs should not be counted either way)
18:54:03 <abadger1999> Okay, so do we want to start discussion on criteria for declaring someone unresponsive today?
18:54:14 <briantist> I do think some time should be spent on criteria, but to felix's bot comment, I might lean toward describing that as guidelines; not something that needs to be strict enough to be automated
18:54:25 <abadger1999> Or do we want to visit another topic and have people bring proposals for criteria next week?
18:54:54 <felixfontein> sivel: it does help in the sense that we know that there's one less maintainer for that module; if the count reaches zero, it's time to think about declaring the module/plugin as orphaned
18:55:02 <tadeboro> sivel: It at least exposes a fact that there is no one maintaining a piece of code, which is usually the first towards some kind of resolution of the "missing maintainers" problem.
18:55:17 <felixfontein> considering that we're already almost at one hour, I guess revisiting this next week sounds good :)
18:55:28 <jillr> sivel: also contributor experience, so folks don't think the 12 people the bot is pinging are likely to reply and so they keep pinging them expecting a different result
18:55:39 <cidrblock> take em all to the orphanage!
18:55:49 <jillr> it communicates expectations more clearly
18:56:01 <felixfontein> sivel: also it's not nice to contributors when they see that X people get pinged for their PR/issue, but nobody ever reacts. reducing the list to avoid them thinking "there are so many maintainers and nobody cares" is good IMO
18:56:06 <abadger1999> #info people who have ideas to define what unresponsive means should add proposed criteria to the ticket and/or bring them to the eeting next week
18:56:16 <sivel> I suppose, although doesn't help them in reality. Instead of 12 people who aren't helping, there are 0 people to help :)
18:56:21 * felixfontein hands abadger1999 an 'm' :)
18:56:37 <abadger1999> heh
18:56:48 <sivel> accept fewer modules from people who aren't active contributors in the first place ;)
18:56:53 <sivel> s/modules/plugins/
18:57:13 <andersson007_> i think repo maintainers should decide who is unresponsive and who is not. They know better. So I'd suggest they use their judgement, first of all. We could develop recommendations
18:57:19 <felixfontein> sivel: you mean, in the initial commit? ;)
18:57:31 <felixfontein> (of the collection)
18:57:41 <briantist> andersson007_: +1
18:58:06 <abadger1999> andersson007_: <nod> So maybe scope should be defined as well... is this just for community.general?
18:58:34 <abadger1999> Or perhaps, this becomes a document for community.general and other repos can point to it and say "this is our policy as well" ?
18:58:39 <andersson007_> abadger1999: also c.network, awx, and a couple of others
18:58:42 <briantist> that's exactly what I think as well, there can be guidelines, but let maintainers set the expectation for their repo
18:59:47 <andersson007_> yes, we could add recommendations https://github.com/ansible/community-docs/blob/main/maintaining.rst
18:59:50 <felixfontein> it probably makes sense to have the document in community-docs
18:59:57 <felixfontein> yep :)
18:59:59 <tadeboro> Some general directions are always niec because "firing" someone is always hard and it helps to have some rught guarantee that you did The Right Thing(TM) is always welcome.
19:00:26 <abadger1999> (I think we'll need a policy for the ansible package too but its implementation will look a lot different... for instance, we don't know about collection maintainers in BOTMETA)
19:00:26 <tadeboro> s/rught/rough
19:00:27 <cybette> cyb-clock chimes: 1 HOUR into meeting, 48 min on topic of unresponsive maintainers
19:00:40 * tadeboro is still sleepy
19:02:15 <jillr> I've got a hard stop, I'm generally in favor of outlining a general policy collections can optionally use for removing unresponsive maintainers, with a clear definition of unresponsive
19:02:24 <cidrblock> in favor of documenting recomendations as a start for collection/repo owners
19:02:38 <cidrblock> hard stop for me, talk soon
19:02:47 * jillr &
19:02:52 <abadger1999> yep, bring proposals for next week, please :-)
19:02:56 <felixfontein> sounds good. then we'll try to collect recommendations for next week's meeting, and then try to decide on some that will end up in a document in community-docs.
19:03:04 <felixfontein> thanks everyone!
19:03:10 <felixfontein> #topic open floor
19:03:24 <felixfontein> so, does someone want to discuss something else?
19:04:03 <tadeboro> How long do we have until next major release and should we start looking at the inclusion requests?
19:04:19 <gundalow> #info If people are interested in testing the new Ansible Matrix server please send me a private message. We will be providing `ansible.im` accounts for people
19:04:46 <tadeboro> I might have some spare time next week, so I was thinking about reviewing a few candidates.
19:05:25 <abadger1999> https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_5.html
19:05:48 <felixfontein> tadeboro: I guess it doesn't hurt to start early
19:06:30 <abadger1999> We have until 2021-10-12.  And yes, please review if you have time.
19:07:06 <felixfontein> I hope that this time, collection maintainers will react quicker to reviews than last time...
19:08:42 <tadeboro> I will try to get things rolling so that we do not end up with n collection being rushed thrugh the process 2 days before the deadline.
19:08:52 <gundalow> tadeboro: Thanks :)
19:09:05 <felixfontein> tadeboro++
19:09:16 <gundalow> When Deric and David are back next week I'll ask them to start looking at inclusion requests
19:12:27 <tadeboro> I am done for today (meetings are no fun and having 36°C/97°F does not help at all). Nice talking to you all and see you tomorrow!
19:12:43 <gundalow> tadeboro: thanks as always
19:12:56 <gundalow> #chair
19:12:56 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr tadeboro
19:13:03 <cybette> thanks tadeboro !
19:13:07 <tadeboro> #unchar tadeboto
19:13:09 <gundalow> Anyone got anything else, otherwise we will close shortly
19:13:13 <tadeboro> #unchair tadeboto
19:13:13 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr tadeboro
19:13:23 <tadeboro> #unchair tadeboro
19:13:23 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ briantist cidrblock cyberpear cybette felixfontein gundalow jillr
19:13:28 <cybette> lol
19:13:33 <briantist> tadeboto3
19:13:33 <tadeboro> Third time is the charm ;)
19:13:35 <aminvakil> :)))
19:13:42 <felixfontein> :)
19:14:03 <felixfontein> thanks everyone!
19:14:05 <felixfontein> #endmeeting