16:00:52 <stickster> #startmeeting Fedora Workstation WG
16:00:52 <zodbot> Meeting started Wed Jan 21 16:00:52 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:00 <stickster> #meetingname workstation
16:01:00 <zodbot> The meeting name has been set to 'workstation'
16:01:07 <stickster> #topic Roll call!
16:01:22 * mclasen is wrapping up another meeting
16:01:47 * ryanlerch_ is here
16:02:26 <elad661> hi
16:02:27 * stickster wrapping up elsewhere too, but should be 100% here shortly
16:03:36 * rdieter waves
16:03:54 <jwb> hi
16:04:06 <stickster> OK, fully here now :-)
16:04:20 <stickster> #chair mclasen ryanlerch_ elad661 rdieter jwb
16:04:20 <zodbot> Current chairs: elad661 jwb mclasen rdieter ryanlerch_ stickster
16:05:02 <stickster> #topic libinput plan
16:05:23 <stickster> Anyone know if Hans is around on IRC?
16:05:44 * stickster not expecting phutterer
16:05:55 <jwb> i cna ping hans
16:06:21 * otaylor is here
16:06:40 <stickster> #chair otaylor
16:06:40 <zodbot> Current chairs: elad661 jwb mclasen otaylor rdieter ryanlerch_ stickster
16:06:49 <stickster> My question for the agenda is, do we have a consensus on the original plan that was posted to the ML? I believe Peter noted for rdieter and others that it seemed like the touchpad issues could be solved in time
16:07:20 * mclasen has to read up on the 'plan'
16:07:21 * cschalle is here
16:07:27 <mclasen> sorry, not fully informed
16:07:33 <hansg> I'm here, but also in a conference call
16:07:42 <stickster> mclasen: I think the original pitch was to add xorg-x11-drv-libinput to the default components in the workstation for F22
16:08:01 <stickster> hansg: ^  (And understood about the call) :-()
16:08:03 <stickster> er, :-)
16:08:10 <mclasen> oh, right
16:08:25 <mclasen> and the complication was that kde is not quite ready for libinput yet ?
16:08:36 <hansg> The original plan was to make xorg-x11-drivers require it, so all products get it, making it part of the default set for workstation was done to give e.g. the xfce people more time
16:09:09 <hansg> In initially the idea also was this would give kde more time, but then it was brought up that kde should be a first class workgroup citizen
16:09:20 <hansg> so now we've agreement on doing a patch for kde
16:09:46 <stickster> Yeah, and I believe rdieter confirmed that a patch would be OK in the interim, with the intent of getting things upstreamed per usual
16:10:05 <jwb> i think the last i saw from Peter is that he's was in contact with upstream and things were going well there
16:10:24 <ryanlerch_> Peter == whot ?
16:10:32 <jwb> yes
16:10:45 <stickster> #url https://lists.fedoraproject.org/pipermail/desktop/2015-January/011396.html
16:10:47 <mclasen> if patching kde seems feasible thats sounds all great to me
16:10:53 <stickster> #link https://lists.fedoraproject.org/pipermail/desktop/2015-January/011396.html
16:11:41 <stickster> The best question here is, do we have any members opposed to going forward, then? And who will take care of the component changes required?
16:12:22 <cschalle> no opposition from me :)
16:12:41 <stickster> I think kalev_ normally does those, but I just want to make sure we track it to done... also I haven't seen Kalev yet.  Which means he's the best person to assign it to :-D
16:13:03 <mclasen> I'll add it as a task on the f22 tasklist
16:13:21 <mclasen> that should give us enough of a reminder to see it to completion ?
16:13:29 <stickster> mclasen: Yup, good enough
16:13:49 <kalev_> oops, sorry for being late
16:13:57 <stickster> #agreed We can go ahead and make changes as suggested; KDE can carry a patch for now, whot is working with upstream
16:14:07 * mclasen goes to do it right now
16:14:09 <stickster> #action mclasen Add to F22 tasklist for tracking
16:14:38 <stickster> Good enough. Let's move on then...
16:15:11 * nirik reads back and notes xfce should hopefully be fine with libinput. Minor patch and thats it.
16:15:27 <stickster> nirik: Thanks for reviewing! That helps.
16:15:30 <stickster> ryanlerch_: We missed your thing on wallpapers for a few meetings. The discussion seems underway on the list, do you need time here or can we go straight to the big item for this week?
16:15:52 * stickster doesn't want Ryan to feel sidelined...
16:15:56 <mclasen> hansg: put your name next to it, hope you don't mind
16:16:25 <hansg> mclasen, that is ok
16:16:29 <ryanlerch_> havent got much feedback on the list yet (on the actual proposal), but lets go to the big item, and talk wallpapers at the end if we get time
16:16:36 <ryanlerch_> otherwise, defer to the list
16:16:42 <stickster> ryanlerch_: OK.
16:16:50 <cschalle> ryanlerch_, sorry for all the digressions caused :)
16:17:03 <stickster> #topic Third party applications
16:17:10 <stickster> #link http://blogs.gnome.org/uraeus/2015/01/19/planning-for-fedora-workstation-22/
16:17:11 <ryanlerch_> cschalle, haha, all good! they were good points :)
16:17:16 <stickster> #link http://blogs.gnome.org/hughsie/2015/01/09/finding-hidden-applications-with-gnome-software/
16:18:13 <stickster> OK, so the purpose here is mainly for us to discuss more specifically what we want to propose for this change, and that what we propose has some chance of passing (in other words, will survive some FESCo/Council decision)
16:18:26 <cschalle> yeah, so I am happy to draft something more concrete up, but I think it should be fairly clear from the blog etc., where I am aiming, so I wanted to get some intial feedback from the working group before starting to draft
16:19:11 <stickster> Some folks wisely pointed out the orthogonal spectra of legality and freedom. I think one thing we probably want to do is figure out which quadrant(s) we care about for our proposal.
16:19:38 <cschalle> I got some feedback from matthew miller already for instance about making sure to put in details about inclusion processes for instance
16:20:02 <mclasen> it is essentially another go at something that was reject by the board a year ago, so we'll have to come up with a careful proposal that avoids some of the trigger items
16:20:47 <kalev_> I am personally very much for making it easier to find 3rd party apps, but it definitely requires some careful balancing to make sure the powers that be don't reject it
16:20:55 <cschalle> stickster, yeah, well it doesn't directly answer your question, but my thought was that we for the initial release this gets targted for pick 3-4 interesting applications that represent different sides of the spectrum and use them to figure out the ground rules and practicalities
16:20:59 <stickster> mclasen: Agreed. I think it will be important to summarize those categories or divisions of what free/nonfree/legal/illegal we are attempting to solve for
16:21:38 <mclasen> I think my contribution on the list can be summarized as: only ask to include free and legal stuff
16:22:43 <stickster> mclasen: I guess it might be helpful to say whether "free" is "freedom" or "freely redistributable" here
16:23:17 <cschalle> I mean to me there seems to be potential corner cases where things are obviously 'legal', like Google Chrome, yet I don't know if Fedora Legal still wants to review the inclusion of repo data for anything that comes with a EULA?
16:23:19 <stickster> If we say free is freedom, maybe we don't care as much here, because something like that could be packaged in Fedora or a COPR, which may be a special case
16:23:49 <mclasen> everything that is in a copr should qualify, certainly
16:23:54 <stickster> s/which/and/
16:24:13 <mclasen> because we're basically as picky about what we allow in coprs than we are for fedora proper
16:24:21 <cschalle> but do we need to verify the coprs? I mean there are rules about what you are supposed to put in a copr, but there is little policing on that I assume?
16:24:22 <stickster> Yeah, if it's a COPR it seems like a no-brainer that we *could* include, just a matter of deciding which to do (yes, this goes back to how we make decisions, but let's hold off there for a moment)
16:25:32 <rdieter> cschalle: I'd argue that is "someone else's problem"(tm) (to verify copr content)
16:25:39 <stickster> cschalle: I'm assuming there is a magic step where we consider the content of the COPR before we propose including it. I'm not mentally filling in that part yet, still trying to figure out if we know what we will *not* propose here in terms of 3rd parties *more* external to Fedora, to narrow down
16:26:06 <stickster> Will we propose e.g. Flash or Chrome, distributed only by a third party?
16:26:41 <stickster> Will we propose any rpmfusion, which may have legal issues?  (I'm guessing not.)
16:27:14 <stickster> It will help the proposal to be explicit about things that we're *not* proposing as well -- so that people don't jump to their own conclusions
16:27:54 <rdieter> I'm with mclasen (if I understand clearly), include only clearly legal and free stuff initially
16:28:05 <cschalle> well my wish is to make the list of stuff eventually offered just be a reflection of 'the universe' as opposed to a carefully edited and put together list. The only question is if there are things we have to blacklist for legal reasons. rpmfusion I guess is one thing we cant will not offer the same goes for the hypotecocal 'app to let you track your sales of crack cocain to preschoolers'
16:28:09 <rdieter> that probably means limiting it to copr's only
16:28:24 <mclasen> stickster: hard to do that if you can't even say the name of the repository :-)
16:28:52 <cschalle> rdieter, well we want to offer 'free beer' stuff here though
16:28:56 <drago01> 'app to let you track your sales of crack cocain to preschoolers' <--- uh ... we have no rules against that
16:29:03 <drago01> unless that is patented ;)
16:29:07 <stickster> "This proposal does not include offering metadata for any repository that has legally forbidden items, whether it is FOSS or not"
16:29:16 <rdieter> cschalle: then we have to verify things
16:29:26 <mclasen> and interesting category outside of copr that we do want to include is stuff that is shipped by third parties and has to be downloaded from there for legal reasons
16:29:32 <stickster> mclasen: Something like Flash or Chrome?
16:29:32 <cschalle> stickster, exactly
16:29:37 <cschalle> stickster, openH264
16:29:45 <drago01> steam?
16:29:56 <ryanlerch_> spotify?
16:30:04 <drago01> dropbox
16:30:24 <mclasen> I don't know the exact legal/freedom classification for all of those
16:30:45 <cschalle> well eventually all of these should be listed, because it should just be 'what is out there' not about 'what we recommend or suggest'
16:30:58 <stickster> Flash: legal_to_offer+, FOSS-
16:31:20 <cschalle> or course for some of them there are details to figure out, like for Steam for instance we might need to hosted elsewhere than rpmfusion to be able to list it
16:31:48 <mclasen> as a tangent, we need to inform the user about all these differentiations we want to make
16:32:07 <drago01> stickster: we could ask rpmfusion to split there repo even more free, freeworld and nonfree or something
16:32:11 <mclasen> so we a) need  to have the classification in the repo files and b) have suitable end-user text for each of them
16:32:31 <stickster> drago01: The only reason something is in rpmfusion is because the legality is questionable.
16:32:49 <drago01> stickster: no or because its closed source
16:32:49 <mclasen> I don't think thats true for all things in there ?
16:32:51 <stickster> (Maybe with the exception of a couple required deps?)
16:33:04 <drago01> its not
16:33:08 <stickster> drago01: Right -- that would be nonfree, sorry.
16:33:16 <mclasen> oh, I guess steam is there due to the dependency on codecs
16:33:19 <drago01> its juts a collection of stuff that "is not allowed in fedora"
16:33:20 * rdieter thinks this discussion may be premature, didn't fesco/board explicity block stuff like this before?  won't that happen again, or have things changed?
16:33:35 <drago01> be it for patents, being non foss or not allowed by policy (kmods)
16:33:37 <stickster> drago01: But yeah, we could ask for that. Let's concentrate on what we can do now, not "if someone else does work"
16:34:00 <stickster> rdieter: The discussion was based on not much level of detail, or implementation.
16:34:21 <stickster> It was very conceptual and hand-wavy. Whereas now we can propose an implementation and specific content.
16:34:44 <rdieter> stickster: I guess my point was since "they" (fesco/board) blocked in the past, ask them for specific circumstances where something like this could be allowed, first
16:34:45 <mclasen> making a more concrete proposal may have a better chance, and the board got replaced by the council...
16:35:15 <stickster> Yeah, although I think it's more about concreteness as opposed to expecting the governance change to magically whoosh away objections :-)
16:35:17 <cschalle> rdieter, well fesco and the board also constantly change, so in any democracy you can always re-open issue after the next election
16:35:47 <rdieter> ok, I just would hate to see a lot of effort spent on something that's dead on arival
16:35:59 <stickster> So has anyone here actually answered the *concrete* question of what they want to propose to include other than free-and-legal COPRs?
16:36:03 <cschalle> rdieter, well the implementation work is already done since we needed it for RHEL anyway
16:36:45 <cschalle> stickster, my 4 sample apps would be Chrome, OpenH264, PyCharm and Steam
16:36:46 <rdieter> cschalle: ok
16:37:20 <stickster> cschalle: That sounds like a pretty good start in terms of addressing our "quadrants"
16:37:24 <mclasen> thats refreshingly concrete
16:38:27 <mclasen> in terms of proposing a policy for additions, I would suggest that we promise to not add any repos that fall outside of 'free and legal' without asking first
16:38:36 <stickster> As noted above, we probably want to be clear we are not proposing legally questionable items
16:38:41 <stickster> mclasen: *jinx :-)
16:38:47 <drago01> cschalle: no flash in that list?
16:39:16 <elad661> flash is slowly dying
16:39:32 <rdieter> mclasen: +1, else conspiracy theorists will assume otherwise
16:39:35 <drago01> its still alive though
16:39:35 <pingou> cschalle: on the otherside, seeing the proposal coming up every 6/12 months by the same people doesn't look good either
16:39:51 <cschalle> drago01, well it is a definite addition to discuss once the rules and setup is done, but having done through 5 Months of discussions with Adobe about Flash in RHEL I don't want to make that our testcase here :)
16:39:54 <stickster> True dat. Flash is still in use quite a bit; you can get by without it more than 5 years ago though
16:40:15 <drago01> cschalle: ok fair enough
16:40:16 <stickster> cschalle: Fair enough. Better to hinge on something we know we can get done.
16:40:30 <mclasen> how do we go about proposing this - write a change request ?
16:40:43 <drago01> concil ticket?
16:40:50 <drago01> get an ack there first?
16:41:04 <cschalle> well I can draft up a policy doc, the working group iterates over it until we can sign off, and then make the change request up to FeSCO
16:41:52 <mclasen> other tasks to do before we are ready to propose this ? do we need a package with those repos for trying it out ?
16:41:55 <cschalle> or to council, although I think it went through FeSCO the last time
16:42:13 <mclasen> it was escalated up through fesco, yes
16:42:19 <cschalle> mclasen, not really, I mean we can emulate this pretty much with what is already available
16:42:19 <stickster> FESCo makes sense although we would want to cc someone(s) on council to be up front
16:43:11 <stickster> We can do that at the proper time
16:43:41 <mclasen> have we solved questions like 'where do you get the pycharm icon' ?
16:43:56 <mclasen> we should make sure that it actually works well for the 4 you want to propose
16:44:16 <stickster> #proposal We'll propose Chrome, OpenH264, PyCharm, and Steam for our initial policy
16:45:01 <cschalle> mclasen, yeah, I just don't want to go to external people with asks before we have an agreement inside Fedora for doing this
16:45:09 <stickster> And know how it works...
16:45:18 <cschalle> yup
16:45:26 <kalev_> sounds good to me, I think that's a good starting list and makes it easier for the council to decide if we have a concrete list of apps
16:46:04 <mclasen> well, even if we don't install the repo files by default, having their repos 'ready' will make things appear better in gnome-software (and other appstream consumers) if the user installs the repo manually
16:46:20 <stickster> cschalle: We will probably want to talk further with hughsie about implementation for user-warning text
16:46:49 <mclasen> I will
16:47:05 <cschalle> stickster, definetly, my idea there is that there is a standard 'fallback' text upstream, but that GNOME Software will look for a translated distro provided file with translated messages and use that instead if available
16:47:09 <mclasen> in fact, I already asked my designers about some of the feedback on hughsies post
16:47:17 <stickster> We need better text upstream, IMHO; but (maybe more importantly?) perhaps this is something where downstream vendors like Fedora will want to override text to match up with how they position themselves
16:47:27 <stickster> cschalle: Ha, *jinx
16:47:41 <stickster> All my ideas are belong to others :-)
16:48:29 <elad661> Just commented on the list that we should probably list the name of the vendor under the name of the app when searching
16:48:32 <stickster> cschalle: let's throw XML at it, everyone loves that :-)
16:48:32 <cschalle> I will make sure to talk about that in the draft
16:48:38 <elad661> so you'd know it's 3rd party before you click on Install
16:48:47 <stickster> elad661: That's a good idea
16:49:09 <mclasen> there's a bit of a question how much and what quality metadata we can get
16:49:15 <elad661> So it'd look like <bold>Steam</bold> \n Provided by Valve Software
16:49:19 <cschalle> elad661: you will not be able to click on install, all 3rd party repos require an extra 'enable' step in the UI which clearly marks them as 3rd party (not against the idea though)
16:50:15 <elad661> you'd probably want the users to know it's 3rd party even after they passed the enable step
16:50:16 <cschalle> s/on install/to install/
16:50:19 <stickster> cschalle: *: Are there other decisions/agreements we need to make here?
16:50:47 <cschalle> stickster, no, I mean anyone feel free to chime in on the mailing list and I hope to have a first draft put up before our next meeting
16:50:55 <mclasen> we just need someone to volunteer for writing a proposal, and iterate it on the list, I think ?
16:51:06 <cschalle> mclasen, already volunteered
16:51:25 <stickster> #agreed proposal on 4 test cases sounds good to everyone who voiced an opinion
16:51:36 <cschalle> (I used to be in the boy scouts, so I am all about volunteering :)
16:51:45 <mclasen> ok, I'll volunteer to drive the testing/fine-tuning of the gnome-software implementation forward by talking to hughsie
16:51:49 <stickster> #action cschalle write draft proposal for 3rd party metadata and circulate to WG before next meeting for comment/iteration on list
16:52:09 <stickster> cschalle: Feel free to call on me for drafting help or once-over editorial pass
16:52:24 <cschalle> stickster, ok will do
16:52:34 <stickster> #action mclasen Work with hughsie on fine-tuning of gnome-software as needed to support policy draft/agreements
16:52:48 <cschalle> I hope to have this on the fedora wiki quick enough that anyone can start helping with proof reading and editing long before our next meeting
16:53:17 <jwb> fwiw, you don't need to CC anyone on the Council for teh fesco ticket.  i can bring it to their attention as the engineering rep
16:54:22 <stickster> jwb: That sounds good. I thought of that also, but I can say it here so I *jinx your idea ;-)
16:54:41 <stickster> cschalle: Awesome.
16:54:53 <stickster> OK, can we give a few minutes back to Ryan then?
16:54:58 <cschalle> sure
16:55:05 <stickster> ryanlerch_: Ha, you get 5 min :-)
16:55:13 <stickster> #topic Wallpaper
16:55:29 <ryanlerch_> so, wallpapers :)
16:55:38 <stickster> #link https://lists.fedoraproject.org/pipermail/desktop/2015-January/011477.html
16:55:58 <stickster> ryanlerch_: Despite the immediate OT stuff... I think this is a good idea and probably overdue
16:56:09 <ryanlerch_> #link https://fedoraproject.org/wiki/Changes/WallpapersCleanup
16:56:21 <stickster> thanks :-)
16:56:38 <ryanlerch_> anyone have any thoughts / questions ?
16:57:18 <cschalle> ryanlerch_, one of the problems you try to fix is to keep the list fresh (as I am reading it), but I don't see that there seems to be a clear way to get new wallpapers in on a regular basis
16:57:19 <stickster> ryanlerch_: I haven't caught up on the thread this morning -ENOTIME. But were you thinking we would have an election for the WPs to include, or just have some primary stakeholders decide?
16:57:40 <stickster> cschalle: Every Fedora release there's a supplemental wallpaper "contest" to include new ones
16:57:48 <stickster> Or at least, there has been for most recent releases IIRC
16:58:00 <ryanlerch_> stickster, yes, that is correct
16:58:15 <mclasen> ryanlerch_: one thought: 1+1+15 is not divisible by 3
16:58:20 <cschalle> stickster, ok, but in the proposal as it currently reads the only new one in a given relase is the new release wallpaper and maybe one form upstream?
16:58:24 <stickster> #info Supplemental wallpapers have been included for most recent releases
16:58:27 <mclasen> you should add one more background to fill the grid...
16:58:27 <stickster> #link https://fedoraproject.org/wiki/F20_Artwork/Submissions/Supplemental_Wallpapers
16:58:42 <stickster> cschalle: I think this refers to just the defaults, is that right ryanlerch_ ?
16:58:57 <ryanlerch_> stickster, cschalle yes, just the defaults
16:58:59 <stickster> Someone can always elect to install a package of additional artwork
16:59:22 <stickster> mclasen: 16, sounds just as good to me. Not 13 though. ;-)
16:59:30 <cschalle> ok, but as I originally asked isn't the goal here to keep the wallpapers list a bit fresher, just replacing 1 default each release isn't that
16:59:33 <ryanlerch_> mclasen, :) good point
17:00:02 <rdieter> cschalle: the supplemental list will refresh each release too
17:00:12 * mclasen wonders if this is a good time to warm up the old 'wallpaper channels' ideas
17:00:59 <stickster> We are out of time unfortunately
17:01:04 <stickster> ryanlerch_: I did it to you again ^^
17:01:13 <ryanlerch_> cschalle, IIRC, the original idea of the supplementals was that they would be the defaults for that release.
17:01:26 <ryanlerch_> but that would mean the entire set would change every release
17:01:40 <stickster> *nod
17:01:45 <cschalle> rdieter, ok, but for someone (like me) who mostly just looks at the default list, the amount of change to it will be very small, especially as the old greatest hits list is not likely to change a lot I would assume
17:02:11 <mclasen> ryanlerch_: embarrassed to ask, but how are supplementals currently distributed ? package ?
17:02:21 <ryanlerch_> the proposal is that this release, we refresh to a set of 15 + 1 + 1 where the 15 doesnt change release per release, but the other 2 do
17:02:46 <rdieter> cschalle: the design team refreshes the supplemental wallpapers every release (afaik), so there should be a good amount of change
17:02:46 <ryanlerch_> backgrounds-extra* i think... let me get the actaul name ...
17:03:08 <stickster> Do we want to include the supplemental package by default then?
17:03:17 <mclasen> some web-based thing would make so much more sense...
17:03:25 <ryanlerch_> mclasen, f21-backgrounds-extras-gnome
17:04:00 <rdieter> stickster: I assume yes ( ryanlerch_ can clarify if otherwise)
17:04:03 * mclasen drifts off into a different meeting
17:04:08 <stickster> mclasen: I have to do that too :-)
17:04:28 <mclasen> just a quick note: just sent a question about webapps for developers to the list
17:04:37 <stickster> ryanlerch_: perhaps we might want to apply some of these clarifications to the change page
17:04:58 <elad661> I agree with mclasen regarding "web based things". Packages are really unfit for this kind of content.
17:05:03 <rdieter> the page does say "A cleaner set of default choices for wallpapers in Fedora"
17:05:05 <ryanlerch_> the proposal as i put forth wasnt to provide the supplmentals as default, it was to choose from that entire set over the 6 releases we have had supplementals to refresh the basic list that hasnt really changed for ages
17:05:12 <ryanlerch_> aka, ladybug on leaves
17:05:17 <stickster> *nod
17:05:45 <stickster> Yeah, I wasn't suggesting otherwise, just trying to clarify, given some of the discussion
17:05:45 <ryanlerch_> elad661, mclasen so if someone installs without internet they don't get wallpapers?
17:06:08 <stickster> Maybe more like, they get some but can bring more in from another source
17:06:19 <cschalle> ryanlerch_, or maybe a installed subset, but the 'universe' available when online?
17:06:26 <elad661> what cschalle said.
17:06:29 <ryanlerch_> this is about the *default* choices
17:06:34 <stickster> *nod
17:06:49 <mclasen> ryanlerch_: the default wallpaper(s) are of course going to be installed locally
17:06:54 <stickster> #idea Orthogonal -- do we want some non-package source available for more art?
17:07:30 <rdieter> stickster: assumes someone is ready to implement that, orthogonal to the proposal at hand (imo)
17:07:37 <stickster> #idea Have 16 wallpapers besides the Fedora + GNOME defaults, to fill the grid to 18
17:07:46 <stickster> rdieter: Exactly
17:08:05 <mclasen> https://debarshiray.wordpress.com/2014/03/18/flickring-backgrounds/ ?
17:08:52 <rdieter> just didn't want discussion of the proposal at hand to get derailed
17:09:23 <aday> fwiw, i posted a suggestion regarding wallpapers to the list
17:09:30 <stickster> ryanlerch_: It seems like no one's opposed (and all are generally in favor) of cleanup, so perhaps we just take the clarifications to the list
17:09:43 <rdieter> ryanlerch_: fwiw, I like it, overdue
17:09:49 <ryanlerch_> the benfit of choosing the 16 from the previous supplementals is that we know they are licenced correctly. they were submitted by fedora community members (not just the design team), ad there is a lot of them to choose from to be able to get a good vareity
17:09:52 <aday> basically suggesting that we manage them as a single set, and stop mixing them from different sources
17:10:07 <elad661> aday: that's a good idea
17:10:09 <aday> so they are consistent, and fit with our branding
17:10:33 <aday> i'd love to have a set that looks like a set, rather than a jumble of images from different sources
17:10:52 <stickster> #idea aday suggests managing the wallpapers as a single set rather than from different sources
17:11:19 <stickster> It might be possible to have some guidelines where our supplemental submissions have a better chance of being in that single set, i.e. being able to turn over a small number per release
17:11:47 <rdieter> isn't f21-backgrounds-extras-gnome already a single set?
17:11:58 <ryanlerch_> aday, what do you mean by a set -- i dont think they choices should be all of the same object, or all of sunsets or something?
17:12:35 <stickster> rdieter: It is, but we may want something with a more distinct palette, or something like that (not sure of the parameters, just saying it could be a different set)
17:12:47 <aday> ryanlerch_: they should be consistent enough to look like they belong together. like, all photos of landscapes, or have a series of abstract images that are variations on a theme
17:13:17 * rdieter thinks that's a good suggestion for the design team picking the wallpapers
17:13:46 <ryanlerch_> that is definiely achieveable from the set of supplementals.
17:15:15 <stickster> Yeah, whatever happens here, we would want to establish how they get picked, and the Fedora Design team should be heavily involved
17:15:58 * stickster tends to think we could collaborate with them to come up with the theme to suggest for supplemental submissions
17:16:20 <stickster> That way, what we get as inputs will tend toward the desired goal :-)
17:16:48 <stickster> But also still encourage people to submit other stuff if they like, and it may still end up in other set(s) whether packaged or elsewhere
17:17:10 <stickster> ryanlerch_: Can we take some of these ideas to list then? We're way overtime, I'm in another meeting, and need to close this out :-\
17:17:40 <aday> ugh, sorry :(
17:19:34 <stickster> No problem... I'll close out but we can go to #fedora-workstation for more discussion, too :-)'
17:19:37 <stickster> #endmeeting