15:01:53 <langdon> #startmeeting modularity-wg
15:01:53 <zodbot> Meeting started Thu Apr 28 15:01:53 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:53 <zodbot> The meeting name has been set to 'modularity-wg'
15:02:06 <langdon> #agenda roll call
15:02:11 <sct> .hello sct
15:02:12 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:02:13 <jkurik> .hello jkurik
15:02:14 <langdon> .hello langdon
15:02:15 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:02:18 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:21 <geppetto> .hello james
15:02:23 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
15:02:27 <contyk> .hello psabata
15:02:28 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:28 <dgilmore> .gday
15:02:29 <jkaluza> .hello jkaluza
15:02:31 <zodbot> jkaluza: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:02:37 <dgilmore> .hello ausil
15:02:38 <zodbot> dgilmore: ausil 'Dennis Gilmore' <dennis@ausil.us>
15:02:47 <haraldh> hi
15:03:14 <bconoboy> .hello blc
15:03:15 <zodbot> bconoboy: blc 'Brendan Conoboy' <blc@redhat.com>
15:03:18 <maxamillion> .hello maxamillion
15:03:21 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:03:40 <haraldh> .hello harald
15:03:40 <zodbot> haraldh: harald 'Harald Hoyer' <harald@redhat.com>
15:03:41 <bconoboy> langdon: remember to #chair some people
15:03:41 <tflink> .hello tflink
15:03:43 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:03:47 <imcleod> .hellomynameis imcleod
15:03:48 <zodbot> imcleod: imcleod 'Ian McLeod' <imcleod@redhat.com>
15:04:00 <langdon> bconoboy, yeah.. planned to do that post naming the voters :)
15:04:04 <maxamillion> imcleod: I did not know that was a bot command :)
15:04:53 * langdon waits til h:05 to move to next
15:05:15 * langdon also badly assumed no one was in a 30m off tz but tried :)
15:05:33 <langdon> ok.. moving on
15:05:38 <langdon> #agenda agenda
15:06:01 <langdon> mild house keeping.. i started an etherpad with agendas.. not sure if it should go somewhere else
15:06:19 <maxamillion> where's the etherpad?
15:06:22 <langdon> #link http://piratepad.nl/modularity-wg-agendas < meeting agendas now live here
15:06:24 <sct> langdon: No strong preference, as long as we don't store notes in it
15:06:33 * langdon notes maxamillion could deal with my slow typing :)
15:06:57 * maxamillion throws a shoe at langdon
15:06:58 <langdon> so c/p to here? or just leave it as a pointer?
15:07:04 <sct> langdon: agree wiki would be better for long term storage; I don't mind where we stick transient agenda stuff.
15:07:12 <langdon> sct, ack..
15:07:26 <contyk> +1 for the wiki
15:07:46 <langdon> contyk, careful. you will be volunteered.. i find wiki "challenging"
15:07:54 <langdon> ok.. lets start for real..
15:07:55 <contyk> I don't mind :)
15:07:57 <sct> I assume we link the meetbot minutes into the wiki anyway?  That way we'll have a record there regardless.
15:08:06 <dgilmore> etherpad for agenda is fine, if we run the meeting right with zodbot we get good minutes
15:08:10 <langdon> #agenda announcement of voting members
15:08:26 * langdon notes dgilmore is asking a lot from me
15:08:36 <langdon> so.. i hope everyone is here..
15:08:53 <dgilmore> langdon: :D you will be fine
15:08:57 <langdon> i tried to pick people based on a wide range of "bias" (can't think of a better word right now)..
15:09:13 <langdon> so.. here is the list.. which i did not prepare before hand.. so give me a sec ...
15:10:35 <langdon> Mike DePaulo, Chaoyi Zha, Harald Hoyer, Tim Flink, Stephen Tweedie, Dennis Gilmore
15:10:36 <langdon> and me
15:11:10 <langdon> so... #chair coming up
15:11:47 <langdon> #chair mikedep333 cydrobolt harald tflink sct dgilmore
15:11:47 <zodbot> Current chairs: cydrobolt dgilmore harald langdon mikedep333 sct tflink
15:11:52 <langdon> #chair mikedep333 cydrobolt harald tflink sct ausil
15:11:52 <zodbot> Current chairs: ausil cydrobolt dgilmore harald langdon mikedep333 sct tflink
15:12:11 <langdon> ok.. everyone down with that? everyone here?
15:12:29 <dgilmore> o/
15:12:39 * haraldh takes a seat...
15:12:48 <langdon> #chair haraldh
15:12:48 <zodbot> Current chairs: ausil cydrobolt dgilmore harald haraldh langdon mikedep333 sct tflink
15:13:05 * langdon notes c/p from wiki != to irc nicks :/
15:13:13 <langdon> ok..
15:13:19 <sct> langdon: That would be too easy.
15:13:21 <haraldh> sorry, harald was already taken :)
15:13:22 <langdon> moving on.. unless someone else has a comment?
15:13:54 <langdon> #action langdon to update wiki with names and lock? the noms page
15:14:28 <langdon> #info new modularity wg voting members mikedep333 cydrobolt harald tflink sct ausil
15:14:42 <langdon> ok.. next agenda topic
15:14:57 <langdon> #agenda review metadata proposal from contyk & new cards from sct
15:15:02 <langdon> #chair contyk
15:15:02 <zodbot> Current chairs: ausil contyk cydrobolt dgilmore harald haraldh langdon mikedep333 sct tflink
15:15:14 <sct> Are we not doing "discuss meeting time"?
15:15:15 <langdon> ok.. sct.. take it away? or do you want some intro?
15:15:19 <langdon> sct, oops
15:15:23 <contyk> :]
15:15:26 <langdon> #agenda meeting time
15:15:41 <langdon> ok... so.. obviously, i like this time.. but am open to suggestions :)
15:15:43 <tflink> what does #agenda do?
15:15:46 <sct> wfm too
15:15:51 <contyk> +1
15:16:00 <langdon> arggh did i screw up zodbot again
15:16:08 <tflink> did you mean #topic ?
15:16:10 <dgilmore> #topic meeting time
15:16:12 <langdon> yes yes i did
15:16:22 <tflink> this time works for me, as well
15:16:28 * maxamillion throws another shoe at langdon
15:16:43 * langdon is starting to have quite the collection of shoes
15:16:50 <dgilmore> this time is fine
15:16:58 * langdon also will be adding #topic to the agenda items so he stops forgetting
15:17:02 <haraldh> +1 for this time
15:17:06 <tflink> sounds like a good opportunity for a side-business - used shoe store :)
15:17:12 <maxamillion> this time works for me also, but I'm more of a chicken in this (re: chicken/pig breakfast scenario) so I'm not sure it matters
15:17:25 <langdon> mikedep333, cydrobolt  haven't seen you .hello .. hopefully this time works ..
15:17:29 <maxamillion> tflink: :)
15:18:00 <dgilmore> maxamillion: i'll take pig and chicken for breaky
15:18:15 <langdon> #info langdon messed up zodbot again.. look for #agenda before here to see the topic breaks
15:18:49 <langdon> ok.. seems like the ayes have it.. we can always change it later if need be
15:19:13 <langdon> #info thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot
15:19:32 <langdon> #undo
15:19:32 <zodbot> Removing item from minutes: INFO by langdon at 15:19:13 : thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot
15:19:37 <langdon> #agreed thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot
15:19:46 <langdon> ok.. now move on?
15:19:51 <sct> yep
15:19:56 <dgilmore> si
15:20:06 <sct> OK, I'll take this one...
15:20:09 <langdon> #topic review metadata proposal from contyk & new cards from sct
15:20:22 * langdon was wondering about the lack of zodbot feedback
15:20:28 <langdon> ok.. sct?
15:20:36 <sct> So, we now have a metadata format for defining modules
15:20:43 <sct> I'm not sure how easy this will be to change over time
15:20:59 <contyk> should be easy
15:21:09 <contyk> but of course it depends on the tools that use it
15:21:11 <sct> but it's worth anticipating a few things we likely need up-front so we're not constantly breaking tools or data compatibility around it
15:21:14 <dgilmore> sct: will it work for non rpm content?
15:21:17 <sct> yeah
15:21:23 <contyk> dgilmore: it will
15:21:49 <sct> dgilmore: In principle, afaik
15:21:59 <haraldh> link?
15:22:15 <contyk> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6TPL3F6RRHU6FTSN4K2TVV33W3J2463V/ the metadata proposal thread on devel@
15:22:21 <sct> There was a brief discussion on fedora-devel, and I've done cards for three additional requirements ---
15:22:25 <dgilmore> I could see debian using it, or having modules with npm, rubygems, etc
15:23:12 <maxamillion> dgilmore: has there been talk of trying to coordinate with debian on the metadata format?
15:23:15 <sct> dgilmore: Yeah.  There are a _lot_ of open questions around things like how to do updates, security reviews, system manifests for non-rpm content etc
15:23:16 <contyk> note the current proposal is already outdated as we plan to add a few more fields here and there
15:23:22 <sct> but in principle it's something we can work towards.
15:23:38 <sct> Anyway, proposals are
15:23:52 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/186?kanban-status=480 --- Define a module's external API
15:24:12 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/187?kanban-status=480 --- Define a module's internal components
15:24:27 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/188?kanban-status=480 --- Add component history to module metadata
15:24:36 * sct cuts-and-pastes furiously
15:24:53 <sct> None of this is a short-term blocker for anything we're doing afaik
15:25:14 <contyk> I agree
15:25:19 <sct> but it all comes out of things we've seen in fedora over the long term
15:25:40 <haraldh> one thing... "requires:" ...  values are the minimum required versions
15:25:48 <sct> mattdm had a really good writeup recently (don't have the link to hand) of how we lose track of why packages get added to the distro
15:25:55 <contyk> haraldh: that's one of the things that might (and most likely will) change
15:26:01 <haraldh> ok
15:26:01 <sct> when somebody wants to add an app and ends up packaging a few random dependencies for that app
15:26:10 <sct> but has no investment in maintaining those dependencies
15:26:12 <dgilmore> sct: most of why we never track
15:26:17 <sct> right
15:26:20 <sct> so
15:26:29 <sct> it's too late to refit that "why is this here" stuff into the distro as a hole
15:26:45 <sct> but I'd *really* like to start out maintaining this sort of information for "why is this thing in this module"
15:27:10 <sct> so we don't end up with the same maintainability questions for modules in the long term.
15:28:18 <sct> Also, I'd like the tools to be able to alert us if dependencies grow unexpectedly, so we've got some way of avoiding unplanned sprawl of minimal installs over time
15:28:50 <langdon> sct, well.. "change at all" right? like i think we want to see modules changing over time ... either larger or smaller
15:28:56 <contyk> it's something our release tools / autoqa could handle, I hope
15:29:02 <langdon> although i suspect it will be "larger" most of the time
15:29:07 <sct> langdon: Change is OK, as long as the tools don't automatically change it for us
15:29:19 <sct> langdon: all I'd like is a manual decision.  Which means spotting when dependencies grow.
15:29:29 <sct> That *could* be done by defining expected dependencies explicitly
15:29:32 <sct> and doing repoclosure
15:29:37 <langdon> sct, i guess i was imaging something like insim with alerting.. like monitoring change of modules over time and the distro as a whole
15:29:41 <sct> and failing a module build until repoclosure passes
15:29:57 <sct> or it could be done with something line insim as you say --- do a test after module build.
15:30:03 <langdon> sct, ohh yes.. i see.. i think there is value to the info eithe rway just for edification
15:30:21 <sct> The reason I prefer the manual decision is that it also means we get to record *why* the dependency was added
15:30:28 <maxamillion> langdon: insim?
15:30:34 * langdon digs for link
15:30:41 <sct> so in years to come, we can look and understand why random-python-library-X is in module-Y
15:30:45 <tflink> would there be enough value in adding something along the lines of rpm changelog to the metadata?
15:30:47 <dgilmore> sct: we can get it automatically also
15:30:49 <sct> and we can determine if it's still needed.
15:30:54 <tflink> as a means of tracking why things changed and when
15:30:56 <maxamillion> sct: +1 - that'd be amazing
15:31:02 <langdon> #link http://insim.fedorainfracloud.org/insim/
15:31:05 <contyk> tflink: please, no
15:31:17 <sct> dgilmore: Right, if we automate the dependency fulfilling then we'd need to automate filling in the why-is-is-here too.
15:31:18 <langdon> #link https://fedoraproject.org/wiki/Insim
15:31:39 <maxamillion> langdon: oh, that's new :)
15:31:55 <langdon> maxamillion, yeah.. very cool... same people did koschei apparently
15:31:56 <sct> tflink: We could, it seems like it would be relatively easy to automate if we had a need for it
15:32:01 <maxamillion> langdon: swank
15:32:05 <dgilmore> sct: indeed, and we suck at manual.
15:32:23 <sct> tflink: but module builds are currently really quick with lubos's stripped-down pungi, and I'd want to avoid excessive processing that slows that down much.,
15:32:33 <sct> dgilmore: Yeah.  The tools will help us either way here
15:32:33 <langdon> contyk why "no"? like that changelog is useful.. i suspect? or do you mean provide it a different way
15:32:41 <tflink> sct: yeah, just was wondering about explicit in-file vs. relying on git commit messages etc.
15:32:48 <contyk> langdon: changelogs are definitely useful but we could easily keep them in git
15:32:58 <sct> either telling us when the manual step is needed, or actually doing the whole thing automatically
15:33:43 <contyk> most rpm changelogs are the same as the package git changelogs; you're just duplicating the information
15:33:46 <sct> Also, defining the external ABI explicitly lets us do stuff like
15:34:01 <sct> do ABI checking via libabigail etc
15:34:17 <sct> and making sure that cross-module dependencies only use external ABIs
15:34:30 <contyk> tflink: we could generate changelogs from git and put them in the repo / image / other deliverables
15:34:50 <sct> none of which we're doing right now, but it sounds useful later on and we can only do it if we maintain the information from the outset.
15:34:55 <tflink> sct: can't we do ABI checking without defining the external ABI explicitly?
15:35:11 <sct> tflink: We need to define which packages represent the ABI
15:35:20 <tflink> contyk: that make sense. it assumes that the git commit log will be useful but then again, so would a changelog
15:35:35 <sct> tflink: eg. I might want PAM to be the official API for authentication stuff
15:35:35 <tflink> sct: ok, I'm thinking about checking ABI on a per-package level
15:35:41 <langdon> so.. +1 for not using changelogs to track info.. but .. i think we need to support an easy "here is what is new in the module" coming straight from the app itself (e.g. changelog).. without manual intervention unless someone wants to add color for a particular module
15:35:53 <sct> and cracklib to be an internal detail that I can swap out later if I need to
15:36:29 <sct> obviously we need both parts in the module for PAM to work, but I can still say that external users should not talk to the internals directly
15:36:47 <sct> And none of this should make our work harder ---
15:36:56 * tflink is thinking of a different problem - has been working on detecting per-package ABI breakage which is not quite the same thing
15:37:01 <langdon> module-abi: in the near term, we can fail to the abi of the rpms in the module, but we need to be explicitly *not* exposing some rpms/binaries as soon as the module-authors realize how useful it is
15:37:10 <sct> if there does turn out to be a need to use cracklib directly, we can ask for it to be made externally visible
15:37:21 <sct> we just shouldn't take for granted that the maintainer intends for that.
15:38:11 <langdon> and.. it is useful to module-authors to be notified when their internal rpms break abi, right? so something we still would like .. just not *between* modules
15:38:40 <sct> So I guess the questions are, is the rational/request here clear, and do we want to maintain this metadata from the start?  We can work out details later as long as we have places to record this sort of thing in the module metadata format.
15:38:40 <langdon> #info fyi, the wiki page of voting members has been update
15:38:44 <contyk> you could use this information to trigger automatic rebuilds of dependent modules
15:38:56 <sct> contyk: Yes, we'd absolutely want to be able to do that.
15:39:00 <langdon> contyk, which information?
15:39:04 <contyk> langdon: ABI changes
15:39:24 <langdon> contyk, ohh definitely.. and which modules need to be triggered instead of mass-rebuilds
15:39:50 <langdon> we want to start a thread on "how can we limit the testing matrix and still be confident of our testing" which is related
15:39:54 <sct> Yes.  And avoiding mass-rebuilds when an internal-only package changes, because we know that that package can't be in use by other modules.
15:40:49 <sct> contyk: Anything else from this that you'd like to discuss while we're on the topic?  We've used a bunch of time on it, and I don't want to swamp the whole meeting
15:41:02 <dgilmore> sct: we can avoid mass rebuilds by tracking what uses what ABI
15:41:15 <contyk> I'd just add that we're currently investigating how module dependencies should be expressed and handled
15:41:18 <dgilmore> regardless of modules
15:41:40 <sct> dgilmore: Yes.  And this goes beyond just modules-as-repositories ---
15:41:40 <contyk> we're also thining about how to build modules and the packages they contain -- I'll send a mail to devel@ with some ideas I have later
15:42:02 <sct> dgilmore: we'd want incremental rebuilds on-demand of higher-level artifacts too, like docker images, anaconda isos, qcow images etc etc etc
15:42:20 <dgilmore> sct: sure
15:42:23 <langdon> ok.. contyk sct any #action / #info you would like to add?
15:42:30 <sct> dgilmore: modules are a part of breaking down the monolithic compose into small, layered builds, they certainly aren't the whole story.
15:42:30 <langdon> or anyone else?
15:42:49 <contyk> hmm
15:42:57 <sct> We can also continue comments/discussion in comments in the cards, or on-list
15:43:01 * langdon notes contyk seemed to imply an #action above ;)
15:43:37 <contyk> #action contyk will send a module build proposal to devel@ for discussion
15:43:44 <langdon> sct, can you send a note to the thread contyk started saying "that" (ie. please see cards x,y,z ro theses logs) ?
15:43:59 <sct> langdon: Good idea
15:44:11 <langdon> then i propose we move on..
15:44:11 <sct> #action sct to reference metadata cards on the fedora-devel thread
15:44:25 <langdon> i have a couple other things i would like to see here today
15:44:33 <langdon> anyone else? 60s
15:45:05 * langdon notes clocks are slow when watching them
15:45:28 <langdon> #topic open bzs
15:45:50 <langdon> ok.. so we have a couple bzs that need some attention.. 1-2 in dnf and 1 in anaconda
15:46:17 <langdon> geppetto, can you #link the anaconda ones? worth raising here? or do you think enough progress is being made?
15:46:33 * langdon notes lkocman is not here who raised the dnf ones..
15:47:10 <geppetto> I can link it … but it's been seen by a bunch of ppl, so I think it's fine
15:47:22 <geppetto> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331100
15:47:46 <langdon> geppetto, ok.. we will move on.. suffice to say.. we need anaconda to honor recommends.. which is really more of an RFE than a bug
15:47:55 <langdon> #info  we need anaconda to honor recommends.. which is really more of an RFE than a bug
15:48:12 <langdon> for dnf we need dep resolution change.. blanking though..
15:48:13 <langdon> help?
15:48:56 <geppetto> IIRC it was yum => dnf compat. stuff … and I thought lkockman was working around it
15:48:56 <contyk> the repo priorities?
15:49:00 <geppetto> Yeh, that
15:49:00 <langdon> ok.. im gonna punt.. the dnf team is aware and committing to help.. but i am totally blanking on the details..
15:49:18 <langdon> and.. i got some help :)
15:49:22 <langdon> but lag..
15:49:32 <langdon> that is it..
15:49:53 <langdon> #info need help in dnf about prioritization of repos for updates. dnf team taking a look already
15:50:12 <langdon> ok.. switching topics..
15:50:18 <langdon> #topic status updates
15:50:40 <langdon> anyone want to provide a #info of what they are up to now? what they plan to demo by next week?
15:51:08 <langdon> i know a number of people are on holiday today
15:51:30 <contyk> we have plenty of spike cards
15:51:33 <geppetto> #info Working on the anaconda/dnf patches to remove weak deps.
15:51:47 <langdon> #info jkaluza to demo status reporting to give a roll up view of taiga http://taiga.fedorainfracloud.org/project/modularity/us/172?kanban-status=472
15:52:01 <sct> langdon: Main one for me is just documentation, writing up what a modular build process could look like
15:52:18 <langdon> sct, do you have a #link which people could follow?
15:52:20 <langdon> or not yet?
15:52:38 <langdon> sct, or maybe a follow up email when a draft is out?
15:52:42 <sct> partly the stuff lkocman has been working on to break down the compose, partly the need to still have the concept of stacks/releases between modules
15:52:51 <sct> Yeah, I'll definitely send it out
15:53:14 <langdon> sct, can i #action an email before next wg meeting?
15:53:38 <sct> Sure:
15:53:51 <sct> #action sct to complete documentation for http://taiga.fedorainfracloud.org/project/modularity/us/183?kanban-status=477 and email to the list
15:53:57 <langdon> cool
15:54:07 <langdon> ok.. next topic? unless anyone has anything to add?
15:54:28 <langdon> #topic inserting item: coverage for next week
15:54:54 <langdon> i meant to add this to the agenda.. i can't make the meeting next week.. kid school meeting.. can someone(s) cover?
15:55:15 <sct> langdon: Sure, let's just plan on discussing agenda beforehand
15:55:22 <langdon> cool.. thanks
15:55:29 <langdon> ok.. last topic..
15:55:35 <langdon> #topic future outreach
15:55:44 <langdon> this could also be called "open floor"..
15:56:07 <langdon> i did want to make sure we follow up with commops to see if they need anything.. decause, you around?
15:56:24 <langdon> but anyone else have any comments/concerns?
15:56:59 <langdon> also, we will have our first recorded demo avail by the next wg (i hope)
15:57:12 <sct> langdon: I think the modularity stuff is incredibly useful
15:57:22 <sct> langdon: but much of it is pretty abstract right now;
15:57:29 <maxamillion> langdon: swank, I'm a sucker for a good demo ;)
15:57:47 <sct> langdon: building a few examples may make outreach a lot easier.
15:57:53 <contyk> who said it's going to be good?
15:58:01 <sct> heh
15:58:04 <langdon> contyk, me!
15:58:31 * jflory7 is around
15:58:39 <langdon> i decided we should stop futzing around with tech for demos and just pre-record them.. then make them avail.. and have people ask qs on the ML...
15:58:56 <langdon> jflory7, y'all need anything re: outreach/onboarding support?
15:59:28 <langdon> someone we should invite to the meetings for "indoctrination"?!?!? bwhahahha
15:59:45 <jflory7> langdon: decause and I were planning on devoting a solid hour or two to catching up on some ticket work, including working on the on-boarding process for Modularity. One thing that would be nice to have would be a formal announcement about the presence of the Modularity WG on the CommBlog.
15:59:54 <jflory7> We could push that out and then promote it across the channels
16:00:12 * langdon notes that sounds like more writing ;(
16:00:13 <jflory7> We identified three things we want to do ASAP for helping out the Modularity WG
16:00:28 <jflory7> (1) Someone can review the contents of their on-boarding wiki page and pass feedback about them in the ticket, as compared to other on-boarding methods in Fedora
16:00:28 <jflory7> (2) Putting together a badge proposal for membership in the Modularity WG (in the form of a ticket on the fedora-badges Trac)
16:00:31 <langdon> sure.. so.. i can write that.. i have another "why modularity" blog post to go soon too
16:00:33 <jflory7> ^^ things CommOps will help with
16:00:39 <jflory7> (3) A Community Blog article announcing the presence of the Modularity WG, what they are, what they do, how to get involved (penned by one of the WG members)
16:01:02 <jflory7> It doesn't have to be super long or detailed, but there is a good example of the Mono SIG's post that was well-received
16:01:04 * jflory7 digs for a link
16:01:52 <langdon> jflory7, in (1) who is the someone? one of us? or your team?
16:01:54 <jflory7> Oh, it was actually their 2015 Year in Review. But it was also a really good chance for them to get some exposure and they had a few interested people pop in after the post was published. https://communityblog.fedoraproject.org/mono-sig-year-review/
16:02:01 <jflory7> langdon: Yeah, someone from CommOps.
16:02:30 <jflory7> decause and I are going to try to tackle (1) and (2) tonight and/or tomorrow.
16:02:36 <langdon> jflory7, on (2) mattdm has volunteered to provide a lego image.. but he doesn't know it yet :)
16:02:46 <jflory7> :)
16:03:15 <langdon> ok.. anyone want some or all of jflory7 (3)? or should i write it? and/or write it and ask for edits?
16:03:41 <jflory7> CommOps can *definitely* help with the editing part too.
16:04:12 <langdon> by "edits" i really meant "color" etc.. your edits have always been good  re: actual content editing
16:04:50 <langdon> ok.. we are over time.. so unless someone wants to volunteer for (3) on the ML.. i will take it
16:05:15 <langdon> #action langdon to write "(3) A Community Blog article announcing the presence of the Modularity WG, what they are, what they do, how to get involved (penned by one of the WG members)" via jflory7
16:05:21 <jflory7> langdon++
16:05:31 * dgilmore has to run to another meeting
16:05:45 * langdon waves to dgilmore
16:06:27 * haraldh has to leave also.. sorry
16:06:28 <langdon> #info jflory7 & decause to work on: " Someone can review the contents of their on-boarding wiki page and pass feedback about them in the ticket, as compared to other on-boarding methods in Fedora" and "Putting together a badge proposal for membership in the Modularity WG (in the form of a ticket on the fedora-badges Trac)" soon..
16:06:39 <langdon> just wanted to gt that last #info in
16:06:47 <decause> .hello decuase
16:06:50 <zodbot> decause: Sorry, but you don't exist
16:06:50 <jflory7> Sure thing. :)
16:06:51 <decause> .hello decause
16:06:52 <langdon> closing meeting in 2m unless someone has something else?
16:06:53 <zodbot> decause: decause 'Remy DeCausemaker' <decause@redhat.com>
16:07:25 <decause> thanks all, happy to help :)
16:07:33 * langdon belatedly waves at haraldh
16:07:55 <langdon> meh.. i don't have the patience for 2m..
16:07:59 <langdon> anyone else?
16:08:14 <langdon> ok.. later y'all..
16:08:23 <langdon> that was 1:30 anyway :)
16:08:27 <langdon> #endmeeting