... UNFINISHED ... WORK IN PROGRESS ...
Summary of Gentoo council meeting 13 September 2015
blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
1. Use flag policies
On the topic of how to structure toolkit use flags, a lengthy
discussion with opposing viewpoints resulted. Consensus was that
manual intervention needed by REQUIRED_USE should be kept to a minimum,
and that users should not need to perform per-package useflag
For approaching the problem systematically it was felt that we need
more information on the current in-tree use cases of the flags and
the objectives that we're actually trying to achieve by setting a policy.
dilfridge volunteered to collect use cases for toolkit use flags,
rich0 to formulate the objectives. Future discussion will focus on the
suitability of the different approaches.
2. Projects without a lead, lead elections
[21:43:18] <dilfridge> agenda topic 2
[21:43:30] <dilfridge> projects without a lead
[21:43:33] <dilfridge> or lead elections
[21:43:35] <jlec> The GLEP defines that yearly a lead election and meeting needs to happen
[21:43:37] <dilfridge> jlec: go ahead
[21:44:01] <jlec> Do we wnat to enforce this or is it just enough that projects function?
[21:44:14] <dilfridge> here's my take
[21:44:16] <jlec> what if no voting happens
[21:44:25] <dilfridge> the GLEP doesnt say how the election should take place
[21:44:26] <jlec> Can simply one dev take the lead?
[21:44:43] <rich0> personally, I'm content to ignore it except when it is a problem, then point to it and call for elections
[21:44:48] <dilfridge> so in principle if team has 3 members and they agree on irc, then they can have a lead
[21:44:49] <ulm> as I read GLEP 39, a team lead isn't even mandatory
[21:44:59] <ulm> "It *may* have one or many leads."
[21:45:06] <rich0> By all means track the lead and last election date on the project pages as a part of the wiki template
[21:45:12] <blueness_> when ppc/ppc64 was "dead" i just "threatened" to take the lead and people came out of the woodwork saying i can't do that, and that revived the projct :)
[21:45:16] <dilfridge> "or" vs "xor"
[21:45:27] <rich0> blueness_: and that is a very effective way to deal with issues when they come up
[21:45:52] <rich0> Many problems can be solved via WP:BOLD
[21:46:05] <dilfridge> "It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months, and may occur at any time."
[21:46:18] <dilfridge> this is kinda silly wording
[21:46:29] <dilfridge> it may have a lead, but the selection must occur
[21:46:34] <blueness_> dilfridge: are you quoting glep39?
[21:46:37] <dilfridge> yes
[21:46:44] <rich0> dilfridge: honestly, a lot of GLEP 39 is silly if you ask me - obviously the result of a lot of compromise, and perhaps a bit of wishful thinking :)
[21:46:49] <ulm> dilfridge: it must occur if the project has a lead
[21:46:51] <K_F> dilfridge: I read it as >=1 leads required
[21:46:54] -*- rich0 won't mention slacker marks
[21:46:57] <K_F> the may referring to 1 or multiple
[21:46:59] <blueness_> let's just ask the leads to put the date up via an email to the gentoo-dev@ list
[21:47:00] <jlec> So we are supporting active projects independent of a lead or how the lead was set up.
[21:47:14] <dilfridge> ulm: that assumption is about as free as the assumption that >=1 lead is required
[21:47:16] <jlec> important is that they just work
[21:47:17] <blueness_> that'll remind them and we can also track project leads that way
[21:47:34] <ulm> dilfridge: yeah, wording could be clearer :)
[21:47:45] <rich0> Groups of people can work effectively without having a lead. However, if a project wants to throw its weight around I think having somebody accountable for the project is important.
[21:47:56] <K_F> but I'm also in the, if there isn't any issue, is there something for us to do ..
[21:47:57] <dilfridge> I would strongly prefer if any project had a nominal lead. Just for having a single point of contact.
[21:48:05] <rich0> ie, project just taking care of a dozen ebuilds that are self-contained, not having a lead isn't a big deal
[21:48:32] <blueness_> dilfridge: i agree, webapp was in that situation
[21:48:40] <dilfridge> I dont care how the election takes place, and how the annual confirmation takes place.
[21:48:42] <rich0> On the other hand, if a project wants to control how others use some global USE flag and there is controversy, the lead really helps
[21:48:49] <blueness_> some user had an issue and there was no point of contact
[21:49:04] <rich0> Don't get me wrong, I think we should recommend strongly that leads get elected
[21:49:17] <jlec> rich0++
[21:49:20] <rich0> I just don't know if we have a good "or else" for when they don't.
[21:49:25] <K_F> rich0: ++
[21:49:28] <dilfridge> e.g., kde team: "!herd kde\n does anyone else want to take the jump seat this year?\n no? \n ok then it's me again..."
[21:49:48] <rich0> dilfridge: there's WP:BOLD again
[21:50:12] <rich0> When people have asked me about advice for disputes within teams I've usually recommended that they do exactly that.
[21:50:35] <rich0> They can call for a team lead election. Maybe the person they like the most doesn't get elected, but now somebody is empowered to deal with their concern, and has some duty to do so.
[21:50:51] <rich0> It provides some kind of resolution.
[21:51:05] <jlec> alright, so we are agreeing that we strongly suggest teams to have leads, but as long as they work it is alright.
[21:51:15] <dilfridge> exactly
[21:51:21] <ulm> well, several of the teams I'm on don't have a lead and work well enough without such bureaucracy
[21:51:25] <dilfridge> now the next question is
[21:51:37] <rich0> jlec: essentially. I don't think it is productive to disband teams that don't elect a lead, remove them from metadata, revoke their aliases, etc
[21:51:43] <dilfridge> should we encourage teams to have a lead, and if so, how strongly?
[21:51:58] <rich0> dilfridge: I think we should encourage it for sure, even as a point of contact
[21:52:02] <blueness_> here's what i suggest
[21:52:10] <blueness_> send an email to gentoo-dev@
[21:52:11] <rich0> Emphasize it on the project page, track the last election date, etc.
[21:52:12] <ulm> I'd leave it to the teams
[21:52:19] <blueness_> remind people of the workding of glep 39
[21:52:23] <ulm> because we cannot enforce it anyway
[21:52:25] <blueness_> encourage them to follow it
[21:52:26] <jlec> dilfridge: just as strongly as encourage simply devs to take it if there is no vote.
[21:52:34] <rich0> Maybe even nag people periodically about their last election date if it is more than 14 months ago?
[21:52:36] <blueness_> and track the date of elections on the project pages
[21:52:39] <rich0> And send a reminder at 11 months?
[21:52:43] <dilfridge> ok
[21:52:52] <dilfridge> I hope you all realize this is a lot of work.
[21:52:59] -*- WilliamH is with ulm
[21:53:08] <rich0> dilfridge: and that is my concern
[21:53:13] <jlec> I would leave it to the teams as well
[21:53:22] <rich0> the tracking on project pages isn't too much work - the teams should update their own
[21:53:27] <dilfridge> Maybe we should deputize some volunteer "team lead election reminder"?
[21:53:33] <rich0> The trying to centralize all that and nag begs automation
[21:53:48] <K_F> I like the date of last election in wiki template idea
[21:54:05] -*- WilliamH isn't really for nagging devs either
[21:54:23] <dilfridge> we can pre-seed it with today's date, and at latest in a year it's >1y in the past
[21:54:26] <rich0> I'd say that step one is at least tracking it on the wiki, consistently
[21:54:35] <rich0> That is a pre-condition for any kind of nagging anyway
[21:54:53] <K_F> dilfridge: I'd favor not pre-setting anything, but have the projects update it themselves, that might force action as well
[21:54:57] <K_F> s/force/encourage/
[21:55:00] <rich0> I could see the counter-argument that team foo says that they work well without a lead and are a model of good citizenship, so why are we bugging them, etc.
[21:55:22] -*- WilliamH agrees with rich0 on that
[21:55:26] <rich0> K_F: agree. I think that project teams should try to give at least some care to their wiki pages
[21:55:37] <rich0> heck, we have issues with devs who don't bother with a wiki account
[21:55:57] <rich0> their project page can be a place to recruit, document, etc. The lead and last election date are just a part of that.
[21:56:09] <K_F> yup
[21:56:21] <jlec> Let's drop that forcing and nagging thing
[21:56:32] <dilfridge> just for the record, a lot of project pages were auto-migrated by maffblaster and me to the wiki.
[21:56:36] <rich0> jlec: I'm fine with that for now. Keep it positive
[21:56:43] <jlec> Let's simply encourage team to to meetings and selections
[21:57:03] <rich0> dilfridge: yeah, it will be interesting to see how many get touched at all, but that is a good sign of team activity
[21:57:26] <dilfridge> ok
[21:57:42] <dilfridge> so we have two things,
[21:58:13] <dilfridge> 1) enhance the project page templates so they show last lead election date (that's something we need to talk to a3li about)
[21:59:01] <dilfridge> 2) write an e-mail to g-project about "please consider electing a lead and confirming her/him regularly", any volunteers?
[21:59:21] <blueness_> i can send the email
[21:59:24] <dilfridge> ++
[21:59:34] <K_F> I can talk with a3li on the template
[21:59:38] <dilfridge> ++
[21:59:41] <blueness_> i'll make it positive and mention both points
[21:59:43] <jlec> great. I think those to points will be sufficient.
[22:00:13] <rich0> wow - we actually got through it all in an hour...
[22:00:17] <dilfridge> :)
[22:00:20] <rich0> (fyi, I do need to drop soon)
[22:00:22] <K_F> :)
[22:00:23] <dilfridge> yes and that's good
[22:00:33] <blueness_> okay so i'm sending this email?
[22:00:34] <dilfridge> 3. Bugs with council involvment
[22:00:36] <ulm> rich0: not having an agenda helps :p
[22:00:43] <dilfridge> blueness_: sure
[22:00:46] <blueness_> k
[22:01:35] <dilfridge> Bug 503382
[22:01:38] <willikins> dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
[22:01:46] <dilfridge> ok we can go on to the open floor
[22:01:52] <dilfridge> 4. Open floor
[22:01:56] <dilfridge> anyone?
[22:02:04] <jlec> I had my topic already.
[22:02:54] <dilfridge> ...
[22:03:06] <ulm> re topic 3. open bugs, I've started working on the 20131210 summary
[22:03:13] <dilfridge> ++
[22:03:28] <ulm> will be finished next time, hopefully
[22:03:34] <K_F> very good
[22:03:43] <jlec> great
[22:03:54] <dilfridge> so seems like noone has anything to bring up
[22:04:06] <dilfridge> which means we can Close This Meeting. (bang) :)