20:02:44 <ttx> #startmeeting tc
20:02:45 <openstack> Meeting started Tue Jan  7 20:02:44 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:48 <openstack> The meeting name has been set to 'tc'
20:02:54 <ttx> Our first meeting of 2014. how time flies
20:03:01 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:32 <ttx> #topic Diversity as a requirement for incubation
20:03:37 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022546.html
20:03:49 <ttx> That one generated a long thread just before the holidays
20:04:02 <ttx> Consensus generally was that we should not *require* diversity before incubation, but require it for graduation instead (options 2/3)
20:04:20 <ttx> Steve Dake's email appeared to win the internet: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022592.html
20:04:41 <ttx> What about 2 or 3 ? Some people prefer 2, some people prefer 3
20:04:58 <ttx> At this point I think requiring "letters of intent" from companies that they would contribute to project Y if it was ever incubated is a bit useless
20:05:06 <sdague> ttx: agreed
20:05:12 <ttx> If we think project Y is relevant, that matters more than a promise of support that might not be followed up
20:05:24 <ttx> So I think I'm going to propose option 2
20:05:31 <ttx> "2. Do not require diversity for incubation, but require it for graduation, and remove projects from incubation if they fail to attract a diverse community"
20:05:44 <ttx> I'll propose it as a patch to reference/incubation-integration-requirements
20:05:54 <ttx> comments / thoughts ?
20:05:58 <dhellmann> option 2 sounds best, but what do we need to change for the graduation requirements to reflect the diversity requirement there?
20:06:15 <dhellmann> and do we need some sort of "out" clause like what appears in option 3?
20:06:17 <mordred> I agree with 2
20:06:20 <ttx> dhellmann: we need to remove the diversity requirement from the incubation part, I think
20:07:10 <dhellmann> sure, I mean, how do we tighten up the graduation requirements to indicate that it is still a part of graduation and that projects that fail to attract a diverse contributor base won't graduation and may lose their incubation status (after some period of time)
20:07:15 <ttx> any project failing to meet graduation requirements can be out, no specific clause needed ?
20:07:58 <dhellmann> we've said projects won't graduate if they don't meet the requirements, but I wasn't aware that "not graduate" might mean "might lose incubation status"
20:08:00 <ttx> dhellmann: i think we can cover that as we visit incubation status more regularly
20:08:02 <dhellmann> or do we not want that?
20:08:10 <mordred> you know - we may not need to have a specific policy on that
20:08:23 <mordred> we could come back to a project that's not gaining diversity
20:08:31 <dhellmann> I wasn't thinking of a specific time frame, just to actually say that we may consider that action
20:08:35 <ttx> we want that, but I think we can cover it in the "incubation" explanation wikipage
20:08:36 <mordred> say "hi, we think you're not gaining diversity, and if you donm't by X, we're going to delist you"
20:08:48 <ttx> mordred: +1
20:08:54 <sdague> yeh +1 to that
20:09:07 * flaper87 sneaks in
20:09:12 <flaper87> that sounds reasonable to me!
20:09:16 <dhellmann> I guess I'm not being clear.
20:09:18 * mordred hands flaper87 a cookie
20:09:29 <ttx> dhellmann: that can be part of our "graduation requirements" feedback
20:09:30 <dhellmann> Does anything in the process document actually say that right now?
20:09:32 <dhellmann> ok
20:10:07 * flaper87 eats that cookie and the rest
20:10:10 <ttx> dhellmann: i'll make sure the docs cover the case and make it clear that incubation is not a permanent status
20:10:21 <dhellmann> ok, that's all I was looking for :-)
20:10:38 <ttx> https://wiki.openstack.org/wiki/Governance/NewProjects has an arrow pointing back up.
20:10:51 <ttx> but I'll add a sentence there :)
20:11:04 <dhellmann> ok
20:11:14 <ttx> #action ttx to propose the change to reference/incubation-integration-requirements
20:11:34 <ttx> #action ttx to make sure https://wiki.openstack.org/wiki/Governance/NewProjects mentions losing incubation status as a possibility
20:11:45 <ttx> anything else on that subject ?
20:12:18 <mordred> nope. that sounds great
20:12:24 * ttx spots a few other rthings that need to be updated on that wikipage anyway
20:12:31 <ttx> #topic Need to recognize/bless projects pre-incubation
20:12:38 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022202.html
20:12:49 <ttx> This was an older thread. If we follow the direction we just decided on diversity as a requirement, I think we solve most of the chicken-and-egg issue that prompted that thread
20:13:00 <ttx> And therefore we don't need to do anything about recognizing projects pre-incubation
20:13:13 <ttx> That doesn't mean we should not track Incubation/Graduation status for projects on some wiki page, though
20:13:30 <ttx> That would not count as "blessing", but would provide easy(ier) reference for all people tracking progress
20:13:40 <mordred> ++
20:13:41 <ttx> does that make sense ?
20:13:53 <jgriffith> Do we want formal checkpoints for this as well?
20:13:55 <mordred> or, in a yaml file somewhere so that it's parseable and stuff
20:14:05 <jgriffith> ie like each milestone..
20:14:06 <flaper87> ++
20:14:11 <dhellmann> yeah, maybe in the governance repo? we need to vote on the status anyway, right?
20:14:14 <sdague> jgriffith: checkpoints would be good
20:14:14 <flaper87> erm, ttx ++
20:14:31 <ttx> mordred: status is actually in the latest projects.yaml change I proposed
20:14:39 <ttx> dhellmann: ^
20:14:41 <mordred> ++
20:14:50 <ttx> vishy: you mentioned to me being interested in having such a reference. Would a wiki page work for you as a tracking tool ?
20:15:28 * jgriffith fears another hidden wiki page
20:15:28 <ttx> mordred: still, gathering our feedback and list of graduation or incubation requirements in some wikipage has some educational value
20:15:57 <ttx> or would you rather have it on some governance file ?
20:16:04 <vishy> yes
20:16:19 * ttx prefers wikipage because it's less like an endorsement
20:16:20 <vishy> or actually i would prefer to just add the extra info the existing page
20:16:39 <ttx> just some "incubation/graduation status" page
20:17:05 <ttx> vishy: the existign page is likely to be replaced by one of the autogenerated pages though
20:17:10 <ttx> (next topic)
20:17:39 * annegentle_ sneaks into the back row and sits
20:17:41 <ttx> anyway, I think we can solve that as we get better at publishing governance docs
20:18:05 <sdague> yeh, agreed, I actually think if we start using the repo instead of the wiki, finding things is going to be simpler
20:18:25 <ttx> things will fall naturally into place as we begin autopublishing
20:18:47 <ttx> which brings us to our next topic
20:18:55 <ttx> unless someone has something to add to this one
20:19:41 * ttx waits for the mandatory minute of lag
20:20:07 <ttx> #topic Governance docs publication
20:20:19 <ttx> So... we need to auto-publish governance docs so that a human-readable version can be found on some webserver
20:20:26 <ttx> Question is.. where and how. Sean originally started to work on this at:
20:20:33 <ttx> #link https://review.openstack.org/#/c/61380/
20:20:39 <ttx> Then Anne questioned this approach at:
20:20:43 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2013-December/000462.html
20:20:54 <ttx> That thread reached consensus that publication to a website (with clear links to the repo) was the right solution...
20:21:03 <ttx> ...but there was still disagreement that docs.openstack.org was the right host for that.
20:21:14 <ttx> Suggestions included www.o.o/governance, www.o.o/tc/governance... but at this point www.o.o is not under our direct control yet
20:21:17 <jbryce> are the artifacts going to be primarily static markup files?
20:21:26 <jbryce> html etc
20:21:28 <ttx> We could easily use governance.o.o or some other subdomain, though
20:21:37 <sdague> jbryce: yes
20:21:40 <ttx> jbryce: I think so, yes. sdague ?
20:21:43 <ttx> ok
20:22:05 <mordred> works for me
20:22:06 <jbryce> we can create a user on www that gives you access to drop files into a subdirectory
20:22:10 <annegentle_> jbryce: so far they're just text, https://github.com/openstack/governance/blob/master/reference/incubation-integration-requirements
20:22:16 <sdague> jbryce: it's basically a very similar publisher to how the development docs go on docs.openstack.org
20:22:22 <sdague> rst -> html
20:22:25 <ttx> annegentle, sdague: had a question about that, actually:
20:22:28 <jbryce> sdague: ok, got it
20:22:36 <ttx> annegentle_, sdague: Can we add some transformation so that, for example, the project.yaml file can be turned into a set of HTML files describing programs and their contents ?
20:22:48 <dhellmann> ttx: we can write a sphinx extension to do that
20:22:53 <ttx> (this question is probably dead stupid)
20:23:04 <ttx> dhellmann: ok
20:23:12 <sdague> yeh, seems like we'd just need some preprocessor
20:23:43 <sdague> but I think that's futures. I think step one is the getting anything publishing, then we can expand
20:23:50 <dhellmann> +1
20:23:56 <sdague> the current review is just a doc build, it's not a publish
20:23:58 <ttx> jbryce: so we could potentially opublish somewhere on www.o.o ?
20:24:11 <jbryce> yep. we have /foundation/tech-committee already and we could create a subdir under that for you to drop files in
20:24:12 <sdague> the publish we'd have to work out as an infra job, to a target
20:24:29 <annegentle_> jbryce: is that subdir accessible via ftp or?
20:24:32 <ttx> annegentle_: would that URL work for you ?
20:24:44 <jbryce> yes, but i'd prefer sftp = )
20:24:47 <annegentle_> I'm fine with anything but docs.openstack.org :)
20:24:59 <mordred> jbryce: we'd prefer sftp too :)
20:25:07 <annegentle_> jbryce: yeah sftp is good
20:25:23 <sdague> yeh, it will mean giving infra root the password, and some assist on the publish job there
20:25:33 <sdague> but I think we can sort that offline
20:25:49 <jbryce> sounds good
20:25:55 <ttx> ok, cool
20:26:00 <ttx> sdague: are we unblocked ?
20:26:01 <annegentle_> jbryce: is http://www.openstack.org/foundation/governance ok? for one less nest?
20:26:15 <ttx> annegentle_:  /foundation/tech-committee
20:26:29 <sdague> ttx: ask annegentle_, she has the -1 on the review :)
20:26:33 <annegentle_> ttx: yeah I'm asking if it's possible to not go under tech-committee
20:26:40 <annegentle_> sdague: I need the commit message amended
20:26:59 <jbryce> i'd rather keep it with the tech-committee as there are other governance-related foundation things that wouldn't be included
20:27:02 <annegentle_> sdague: then I'm happy to +1
20:27:09 <sdague> annegentle_: I continue to be confused about that. Can you put exactly what you'd like in the commit message in a comment
20:27:21 <annegentle_> sdague: delete all mention of docs.openstack.org
20:27:48 <ttx> jbryce: would www.o.o/tech-committee be an option ?
20:28:07 <ttx> or does it have to match the top nav
20:28:13 <annegentle_> sdague: suggested edits on review
20:28:57 <jbryce> we're getting ready to refresh the foundation section and nav overall and i think it would be neater for the long term to have the hierarchy
20:28:58 <dhellmann> are we going to try to make the theme of these docs match the theme of the rest of the site?
20:29:07 <ttx> annegentle_: we'd probably move the membership down to /foundation/tech-committee/members
20:29:22 <jbryce> for instance, we can probably decorate basic markup files to add the nav/them of the website
20:29:24 <ttx> so the rest could be published under /foundation/tech-committee directly
20:29:26 * dwchadwick slaps ayoung around a bit with a large trout
20:29:29 <jbryce> if we keep it in the hierarchy
20:29:48 <ayoung> smoke me a kipper
20:29:49 <annegentle_> jbryce: dhellmann: I'd prefer the files match the rest of that site
20:30:05 <dhellmann> I don't think it's a good idea to have anyone else editing these files after they are published. Anything that needs to be changed should happen as part of the publishing process, in the job run on -infra
20:30:17 <jbryce> dhellmann: i'm pretty sure we can get that for free with the hierarchy
20:30:45 <jbryce> dhellmann: decoration in real-time, without touching the content of the files that are transferred
20:31:00 <sdague> ok, so there is phase 2 here for publishing that includes theming to match the foundation site
20:31:04 <ttx> fancy
20:31:13 <dhellmann> jbryce: ok, so we'd need to know what skeleton html format would be needed to make that work out properly
20:31:15 <jbryce> e.g. file says <div>governance is awesome</div> and the web server adds the headers and footers when the page is served
20:31:23 <jbryce> dhellmann: roger
20:31:48 <sdague> do we have a volunteer for that, I'm afraid that will die on the vine?
20:32:08 <ttx> lets' start by publishing the charter under /foundation/tech-committee/charter and iterate from there ?
20:32:38 <sdague> with the existing sphinx theme? or did we just say we couldn't until we had the new templates
20:33:07 <ttx> I think existing sphinx theme is better han no publication at all
20:33:12 <sdague> ok
20:33:19 <dhellmann> I agree. Creating a whole new theme is going to take some time.
20:33:22 <jbryce> you can drop whatever you want in there and it might be easiest to start with the existing theme just to get the publishing mechanics down
20:33:25 <ttx> we'll just not advertise that URL that much until it's clean :)
20:33:47 <sdague> works for me, I can continue to shephard through the existing theme publish to get the minimum working
20:33:56 <annegentle_> thanks sdague
20:34:15 <jbryce> sdague: feel free to ping me offline for the publishing piece
20:34:15 <sdague> annegentle_: review updated
20:34:38 <sdague> jbryce: will do. As we need infra folks, it will wait until next week when they are back to full staff
20:34:46 <sdague> fungi is being run too rampant this week
20:34:47 <ttx> #action sdague to drive governance autopublication step 1: get the charter autopublished under www.o.o/foundation/tech-committee/charter
20:35:11 <ttx> then we'll seek volunteers for the next steps
20:35:23 <ttx> anything more on that topic ?
20:36:08 <ttx> (mandatory minute of lag again)
20:36:23 <annegentle_> none here
20:36:33 <ttx> let us all observe a minute of silence while the topic dies
20:36:40 <ttx> #topic Mention scope expansion in incubation requirements
20:36:47 <ttx> #link https://review.openstack.org/#/c/62612/
20:36:53 <ttx> That one was abandoned over the holidays
20:37:02 <ttx> There were a few -1s about the specific language around this, with some consensus around "measured progression".
20:37:12 <ttx> jgriffith had a -1 around the idea itself, though
20:37:27 <ttx> Personally, I think it's good to have this in the requirements, as it gives us some leverage to reject projects "just because there are too many projects in incubation already"
20:37:42 <ttx> Because we might need to reject projects purely on bandwidth reasons at some point, and "measured progression" is what it's about
20:37:49 <jgriffith> ttx: I guess the problem I have is how do you enforce it?
20:37:54 <jgriffith> ttx: it's awfully subjetive
20:37:56 <jgriffith> subjective
20:38:20 <mordred> I thnk I agree with jgriffith
20:38:24 <ttx> jgriffith: I see your point
20:38:30 <ttx> most of the other requirements are objective
20:38:34 <mordred> I think that we don't need to enumerate everything that we might have a subjective viewpoint on
20:38:36 <annegentle_> amen to bandwidth reasons
20:38:43 <jgriffith> mordred: :)
20:39:01 <mordred> we may make decisions basesd on bandwidth - but we may make decisions based on many htings that are judgement calls - that's why we're a body of humans
20:39:02 <annegentle_> but yeah we'd have to have a metric/measurement other than ttx and infra and docs are swamped :)
20:39:16 <mordred> annegentle_: I think that's an excellent measurement
20:39:26 <jgriffith> ttx: I suppose the more I think about *something* does need to be there for incubation
20:39:29 <mordred> but I don't tihnk we need to pre-tell people about it
20:39:30 <ttx> mordred: fine with dropping it as long as it's clear that incubation relies on finite resources and some perfectly-good projects might have to wait for their turn at some point
20:40:05 <mordred> ttx: I guess I'm just saying that we needed to be clear about the diversity thing because it became an issue for projects and a planning issue and is a real problem to solve
20:40:11 <annegentle_> mordred: anne's hair on fire metric
20:40:16 <ttx> we established that 3 in incubation and 2 new integrated projects per cycle was doable
20:40:24 <mordred> I'm not sure that us mentioning that we are worried about finite resources does anything to solve a problem that we currently have in communication
20:40:31 <sdague> agreed
20:40:39 <ttx> I'm pretty sure 6 in incubation or 4 added per cycle would be too much
20:41:22 <jgriffith> ttx: sdague mordred sorry... I may be confused on the intent here
20:41:22 <ttx> agree, let's let that requirement die
20:41:35 <mordred> jgriffith: I'm always confused
20:41:39 <ttx> jgriffith: I think we agree with you
20:41:41 <jgriffith> ttx: limit projects per cycle I get
20:41:44 <jgriffith> Ok :)
20:41:48 <jgriffith> mordred: ditto
20:41:56 <annegentle_> ttx: mordred: even communicating these limits could just mean a need for waitlisting, etc. Sigh.
20:42:35 <ttx> annegentle_: and you can't really come with hard numbers. Some projects need more care than others.
20:42:45 <annegentle_> ttx: truth
20:42:47 <ttx> I think it's just at some point one of us will scream
20:43:07 <ttx> hard to predict when.
20:43:18 <jgriffith> just a moment ago :)
20:43:29 <mordred> yup
20:43:36 <ttx> ok, anything more on that subject ? We'll let that change remain abandoned
20:43:55 <ttx> maybe markmc will revive it and defend it bettert than I did
20:44:44 <ttx> #topic Open discussion
20:44:49 <ttx> Anything else, anyone ?
20:45:08 <sdague> nothing from me
20:45:14 <ttx> I recently proposed a project/program map into programs.yaml
20:45:29 <ttx> which asks plenty of fun questions
20:45:36 <ttx> #link https://review.openstack.org/#/c/65096
20:46:10 <ttx> like is grenade a devstack or a QA thing
20:46:26 <sdague> ttx: it's QA
20:46:31 <ttx> or like is openstack/requirements a Release management or a Infra thing
20:46:32 <sdague> that was previously established
20:46:36 <ttx> mostly academic questions
20:46:44 <ttx> sdague: cool, thx
20:47:04 <ttx> or is storyboard an infra or release management thing
20:47:24 <ttx> so feel free to tear it apart
20:47:45 <ttx> thera re also a number of openstack*/* projects that have no parent program
20:48:13 <ttx> openstack-dev/openstack-qa
20:48:13 <ttx> openstack-dev/sandbox
20:48:13 <ttx> openstack/governance
20:48:13 <ttx> openstack/melange
20:48:13 <ttx> openstack/openstack
20:48:14 <ttx> openstack/openstack-chef
20:48:15 <annegentle_> ttx: I like your academia
20:48:16 <ttx> openstack/python-melangeclient
20:48:18 <ttx> openstack/python-openstackclient
20:48:20 <russellb> should we have an orphan section?  heh
20:48:23 <ttx> some of them may just need to die
20:48:31 <ttx> melange/chef
20:48:36 <annegentle_> now ttx is killing orphans
20:48:44 <ttx> some badly need a home (python-openstackclient)
20:48:57 <ttx> sdague: is openstack-dev/openstack-qa a real thing ?
20:48:57 <russellb> there is chef stuff actively developed on stackforge
20:49:00 <mordred> actually - we've talked about melange before
20:49:06 <mordred> and how to handle it
20:49:08 <sdague> ttx: it's a very old artifact
20:49:10 <mordred> because it's not a real thing anymore
20:49:16 <mordred> but I don't like the idea of deleting it
20:49:24 <mordred> since it _was_ a real thing in the past
20:49:25 <ttx> sandbox openstack/openstack and governance can stay in limbo because they are true orphans I think
20:49:31 <jgriffith> archive grouping
20:49:33 <mordred> openstack-chef is bonghits and can be deleted
20:49:45 <sdague> openstack-attic
20:49:50 <mordred> I suggested to jeblair a while back moving  melange to stackforge
20:49:51 <jgriffith> sdague: +1
20:49:57 <mordred> so that should anyone want to do anything with it, they could
20:49:59 <russellb> yeah stackforge seems fine
20:50:00 <sdague> if we want to keep stuff around, lets get it out of real namespaces
20:50:08 <markmcclain> sdague: +1
20:50:22 <ttx> I'd like to have only prgram children or true orphans in openstack*/*
20:50:24 <jgriffith> I'm not so sure how I feel about stackforge
20:50:33 <jgriffith> but if nobody else has an issue ok by me
20:50:35 <ttx> so that we can generally say "contributing to openstack*/* gives you ATC rights
20:50:49 <russellb> stackforge means nothing about how active something is
20:50:52 <russellb> or whether it's crap or not
20:50:53 <sdague> I don't think putting dead projects on stackforge is productive
20:50:58 <ttx> mordred: could we kill openstack-dev/sandbox while we are at it ?
20:51:05 <jgriffith> russellb: that last point is kinda the problem I have with it :)
20:51:11 <sdague> russellb: yeh, but lets not make it sourceforge, the home of dead projects
20:51:19 <jgriffith> LOL
20:51:19 <russellb> heh
20:51:21 <ttx> don't really want commits to that to count as atc-granting
20:51:23 <sdague> so if we know it's dead, throw it in the attic
20:51:25 <russellb> that's funny..
20:51:28 <russellb> attic is fine i guess
20:51:44 <jgriffith> now we need a basement and we'll be all set
20:51:56 <russellb> attic can be dead stuff from openstack/
20:51:56 <ttx> isn't stackforge the basement ?
20:52:00 <sdague> openstack-rootcellar
20:52:00 <ttx> or is it the garage ?
20:52:05 <russellb> we could create a basement for dead stackforge projects
20:52:05 <jgriffith> ttx: shed
20:52:10 <russellb> stackforge-basement and openstack-attic
20:52:10 <dhellmann> sdague: beat me to it
20:52:11 <jgriffith> russellb: LOL
20:52:46 <ttx> I would do attic/ rather than openstack-attic, so that openstack*/ matches all "official" projects
20:53:01 <ttx> as in atc-rights-granting
20:53:07 <sdague> ttx: I doubt we're ok to grab github.com/attic
20:53:13 <jgriffith> ttx: good strategy IMO
20:53:26 <ttx> sdague: sounds risky
20:53:28 <mordred> ttx: we use openstack-dev/sandbox
20:53:40 <sdague> anyway, we could sort out naming offline
20:53:54 <sdague> if we are agreed that there should be an "attic"
20:54:02 <russellb> wfm
20:54:08 <ttx> sdague: bikeshedding is what open discussion is for
20:54:14 <russellb> yeah it is fun to bikeshed
20:54:17 <ttx> mordred: oh
20:54:42 <jgriffith> more bikeshedding would greatly improve the world
20:55:01 <sdague> then I'd have all kinds of places to store my bike
20:55:03 <jgriffith> There's always some good humor hidden there
20:55:08 <ttx> mordred: I guess we could count sandbox as a true orphan too
20:55:09 <jgriffith> sdague: OHHH!!!
20:55:10 <annegentle_> stackforge is a garage, baby
20:55:17 <jgriffith> forget attic... "bike-shed"
20:55:47 <ttx> btw, file extensions on .gitignore wins the openstack-dev thread of the week
20:56:38 <jgriffith> ha!
20:56:54 * jgriffith laughs.. then cries
20:57:11 <ttx> mordred: looking at http://git.openstack.org/cgit/openstack-dev/sandbox/ I think nobody would miss it, but please enlighten me
20:59:09 <ttx> I guess that's all for today ?
20:59:27 <mordred> ttx: jeblair made it so that people could 'practice' with our process/tools
20:59:55 <ttx> mordred: could it live on stackforge instead ?
21:00:17 <ttx> mordred: i'm fine with making it a true orphan if not
21:00:50 <ttx> and.. no time left
21:00:56 <ttx> #endmeeting