19:00:13 <jbryce> #startmeeting
19:00:14 <openstack> Meeting started Thu May  5 19:00:13 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:30 <jbryce> hello ttx and ewanmellor
19:00:38 <jbryce> who else is here?
19:00:39 * ttx hopes it will stay short, so that he can go back to his vacation schedule :)
19:00:47 <eday> here
19:01:08 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda items
19:01:23 <jbryce> ttx: we can try!
19:01:51 <ttx> do we have quorum ?
19:01:57 <vishy> o/
19:01:57 <johnpur> here!
19:02:07 <anotherjesse> here
19:02:07 <ttx> those extra three should help.
19:02:22 <jbryce> we've got 7 now, so we can get started
19:02:36 <jbryce> #topic OpenStack project model
19:02:57 <jbryce> eday did you see the 2011 scope and charter doc that johnpur had put together previously?
19:03:16 <eday> jbryce: I don't think so
19:03:28 <jbryce> http://wiki.openstack.org/Governance/Approved/2011%20Charter%20and%20Scope
19:03:57 <eday> oh wait, perhaps I did see that
19:04:03 <anotherjesse> jbryce: I think it is missing identity/authorization
19:04:19 <jbryce> i think the intent is similar to your definition of integrated/loose project-level controls
19:06:09 <ttx> I think we are a bit between Linux and Ubuntu in your descriptions.
19:06:32 <ttx> i.e. a bit more controlled than Ubuntu.
19:07:07 <johnpur> Somehow we need to maintain a degree of control, while allowing max transparency
19:07:17 <eday> jbryce: yeah, it does seem to cover some of it
19:07:32 <jaypipes> o/
19:07:43 <ttx> I can tell from experience that complete lack of upstream control is a problem, and full control is probably not desirable.
19:07:43 <johnpur> what is not clear is who has decision making authority, to stop the endless community debate on everything
19:07:56 <ttx> So "tightly integrated with some level of control" :)
19:08:12 <jbryce> ttx: that's how i see it
19:08:19 <jbryce> johnpur: it depends on where the debate happens
19:08:21 <eday> johnpur: I don't think the control/integration properties will affect transparency in any way... but it is something we need to emphasize :)
19:08:29 <ttx> PTLs have, with appeal to PPB. Unless for cross-project decisions, where PPB has ?
19:08:44 <jbryce> that should be the model now
19:08:48 <johnpur> ttx: yes for technical project issues
19:09:05 <ttx> johnpur: define non-technical project issues ?
19:09:10 <ttx> summit location ?
19:09:36 <johnpur> discussion channels, splitting dev/user discussions, what forum software
19:09:39 <vishy> IMO, that control will have to increase a bit over time.  It is clear that projects aren't going to agree on certain things that are really important to be standardized.  At some point we have to realize that for OpenStack to succeed as a complete platform, projects are going to have to stop trying to adopt the "best" solution, and start focusing on adopting the same solution.
19:10:04 <ttx> vishy: I love you. Will you marry me ?
19:10:06 <johnpur> summit location is in the purview of the community manager
19:10:20 <ttx> ttx: err. I'd have to divorce from my wife first.
19:10:53 <jbryce> vishy: i agree
19:11:00 <eday> vishy: this is exactly what I was trying to get at. should we be enforcing openstack-comon things, or just suggesting them? If so, I think the release changes we decided on at the summit may have been a step in the wrong direction (for integration)
19:11:07 <johnpur> ttx: many user/devops/operations issues will not be "technical"
19:11:33 <jbryce> johnpur: the non-technical items kind of bleed into the second agenda topic
19:11:44 <johnpur> just saying :)
19:12:50 <vishy> eday: I think if we spend some time winning developers over to the idea that we need commonality will be a lot more successful than trying to enforce it
19:13:03 <eday> if we really want a well integrated stack, this means a lot of common work needs to be done with existing projects, and the bar is raised quite a bit for new projects coming in (as far as integration requirements)
19:13:12 <vishy> s/ will/, it will
19:13:23 <vishy> eday: +1
19:13:28 <eday> vishy: agree, that's more of an implementation detail :)
19:14:17 <ttx> eday: At some point we may need to enforce it. Though I hope we can convince people to do the right thing instead.
19:14:32 <eday> ie, gflags, logging, common conf, etc all need a fair amount of work with existing projects if this is the direction we want to head, and afaict, no resources have been allocated for those
19:14:44 <jbryce> with the PTLs now in place and members of the policy board, i think it makes it easier to decide on things like what eric is talking about. if openstack-common should be suggested or required use for it's functionality. but i also think that requirements like that need to be phased in.
19:14:46 <ttx> eday: to that effect, we need to state that commonality is a goal.
19:14:48 <anotherjesse> things like API/auth/user models should be shared
19:15:02 <vishy> the only thing we agreed on standardizing is a library for swift-init
19:15:09 <eday> ttx: yup, so far it's not been clear of suggestion vs requirement long-term
19:15:11 <jbryce> in other words, maybe the PTLs come up with a recommendation about the end state, steps to get there, and their buy-in to lead their projects there over x releases
19:15:51 <ttx> eday: I think it's required, though options parsing doesn't have the same prio as identity service, obviously
19:16:09 <vishy> so does that mean notmyname, jaypipes, myself and eday should discuss it?
19:16:34 <eday> vishy: I'm not a PTL :)
19:16:47 <johnpur> when do we bring in the other projects to the discussion?
19:17:15 <eday> johnpur: I don't think we should consider new projects until we decide how the current ones should play together and can offer the common requirements list
19:17:21 <jaypipes> johnpur: I've already brought keystone into the discussion to change their direction to utilize some of the common code around wsgi/daemon stuff.
19:17:23 <eday> if thats the direction we want to go, anyways
19:17:40 <vishy> eday: well i was thinking your input would be good as a representation of future projects trying to integrate
19:17:40 <jbryce> vishy: i think we can all discuss it, but i think PTLs saying "yes, i believe this is the best thing for my project and i'm going to help us get there" is better than just a mandated policy
19:17:55 <johnpur> i just want to give early guidance, if we can, so they don't get too far off track
19:17:57 <eday> vishy: sure, would be happy to contribute where I can
19:18:11 <vishy> i'm 100% for integration
19:18:35 <jbryce> and considering that you all know what is going to be really painful or really useful, i think it makes more sense to have it generated from your side than from a theoretical policy side. make sense?
19:18:51 <johnpur> jbryce: +1
19:19:07 <eday> johnpur: agreed, but I'd hate to tell new projects to use something the PTLs will decide against later. we shoudl sort this out asap
19:19:30 <vishy> we have had requests from the new projects for a kind of standard template for creating a new service.  Something like that would be incredibly useful...
19:19:30 <johnpur> early guidance, but too early?
19:19:55 <vishy> (since we have 3+ starting right now)
19:19:59 <eday> vishy: agreed
19:20:23 <jbryce> ok...so it sounds like most of us who have been talking agree that we see openstack as a collection of tightly integrated projects with some level of control to ensure common behaviour is consistent, uses shared technology, etc.
19:20:25 <eday> vishy: do you want to coordinate a ptl meeting to make a requirements list and plan existing projects to switch to them?
19:20:45 <vishy> ok
19:20:58 <jbryce> eday: that was going to be my next suggestion. thanks!
19:21:11 <vishy> where are the resources coming from? Just hoping the community will step up here?
19:21:50 <jbryce> i think the agreement on what will be commonly required is more important up front
19:22:00 <jbryce> so we can give that early guidance to all the new projects that want to get started
19:22:24 <vishy> ok i'll send out an email and we'll try and get on a call/irc
19:22:31 <eday> vishy: I'm guessing if we mail out the plan, someone will step up
19:22:34 <jbryce> we can figure out the process to get legacy projects switched over, but it would be great if we could keep new "legacy" projects from getting started
19:23:19 <jbryce> #action vishy to schedule meeting with PTLs and other interested parties to discuss common requirements across projects
19:23:42 <jbryce> vishy: can you just keep the whole PPB list in the loop on that as well so anyone can participate as they desire?
19:24:16 <vishy> sure
19:24:16 <jbryce> any other discussion on this item?
19:24:27 <eday> we should also have a short, concise summary about what OpenStack is somewhere too (controlled+integrated)
19:24:48 <eday> maybe making a comparison to a model most people will understand (like Linux/subsystems)
19:24:59 <vishy> should i make the meeting public so everyone can come share their opinion? or keep it small?
19:25:13 <ttx> I think we'll be exercising less control than the Linux model.
19:25:36 <ttx> so "somewhat-controlled + tightly-integrated"
19:25:47 <eday> ttx: ok
19:26:30 <jbryce> eday: do you want to draft something along those lines for us to look at?
19:26:48 <ewanmellor> I'd rather see a description of our behaviour, than a reference to other people's models.  "The Linux model" is probably something that people understand.  "The Apache model" is so meaningless to me, it's not a good analogy.
19:26:58 <ewanmellor> Ditto "the Ubuntu model".
19:27:15 <ttx> I can work with eday on that.
19:27:20 <ttx> next week.
19:27:49 <jbryce> vishy: i could see it either way in terms of the group to discuss. might be nice to start smaller.
19:28:07 <jbryce> #action ttx, eday to draft a short description of the OpenStack project model
19:28:27 <eday> sure
19:28:37 <jbryce> ok...next....
19:28:44 <jbryce> #topic shared OpenStack resources
19:29:03 <vishy> jbryce: agreed, we'll start small PTLs + anyone who is interested from the PPB, then expand to greater community when we have some consensus
19:29:48 <jbryce> this is an interesting one for us to discuss because i'm not sure the PPB actually has the responsibility for some of these resources
19:30:17 <eday> jbryce: such as?
19:30:29 <jbryce> use forums for instance
19:30:30 <jbryce> user
19:30:40 <ttx> I guess the problem is, the only Openstack-representative body currently is the PPB, so it makes sense that it's called to decide on things
19:30:40 <vishy> jbryce: agreed, but i think we can request from the current owners that they attempt to be as open about the process as possible
19:30:53 <eday> well, if we host it, we do :) unofficial not at all
19:30:53 <jbryce> i agree with both of you
19:31:17 <ttx> even though the trademark is Rackspace property.
19:31:40 <ttx> I meant that last sentence as a question, not a statement.
19:31:47 <vishy> so the two main points of contention are openstack.org and launchpad groups right?
19:32:00 <jbryce> but i think where we actually have a mandate to set policy is around projects and their ability to be recognized and associated with openstack and make use of openstack resources
19:32:48 <ewanmellor> I think we have a mandate to make decisions on openstack.org too.  I know that Rackspace own the trademark and the domain, but they (Lew) have made it clear that they are holding these for the community, not as Rackspace assets.
19:33:03 <ewanmellor> And we're the only representative board for the community.
19:33:17 <vishy> ewanmellor: I don't really want to make decisions on openstack.org
19:33:28 <jbryce> when we say openstack.org are we talking website or domain name
19:33:33 <ewanmellor> vishy: Someone has to.
19:33:37 <eday> so, forums.openstack.org, jenkins.openstack.org, etc, are PPB controlled, so to speak
19:33:45 <johnpur> and we are back to my point
19:33:53 <ttx> ewanmellor: what about the advisory board, with PPB having veto power ?
19:33:58 <jbryce> for domain name, i think we should definitely lay out what the requirements are for a project to make use of openstack.org subdomains, etc
19:33:58 <ewanmellor> eday: Yes, that's what I mean.  I think we should own those.
19:34:12 <ttx> (whenever the advisory board will be set up)
19:34:16 <eday> and with the tightly integrated model, we should probably be requiring these assets be used for approved projects
19:34:23 <johnpur> we need a mechansm to make community driven decisions that rae not "technical" about the project
19:34:24 <ttx> then vishy doesn't have to care about it, until it causes problems.
19:34:29 <eday> the Q is what about non-approved projects. should burrow.openstack.org go away for now?
19:34:45 <vishy> ewanmellor: if we do have some kind of control here (which I'm not totally sure about), I'd prefer to delegate management of these things to someone else
19:34:52 <jbryce> vishy: +1
19:35:01 <jaypipes> ++
19:35:14 <jbryce> thierry is the release manager
19:35:16 <johnpur> delegate to whom?
19:35:21 <johnpur> not ttx
19:35:22 <jbryce> he makes decisions on feature freeze exceptions, etc
19:35:23 <vishy> I think in general the current team is doing quite well
19:35:33 <jbryce> hold on a minute and let me finish my point. = )
19:35:40 <vishy> aside from a few screwups around too many people having access
19:35:43 <ewanmellor> vishy: I didn't mean that we would have to be sysadmins.  We can certainly delegate.  But it's up to us to decide when a thing should be blessed with the OpenStack name, and when it shouldn't.
19:35:54 <jbryce> but ttx has a clearly defined process and it happens in public
19:36:11 <ewanmellor> And by "decide" I mean "set clear, transparent policies, and then arbitrate if necessary"
19:36:31 <jbryce> i think the issue with some of the non-technical assets is they are a little black box right now
19:36:32 <ttx> jbryce: right, I can always be vetoed by the PPB. That's delegation.
19:37:15 <ttx> jbryce: so we could also delegate some parts of openstack.org user-oriented stuff
19:37:22 <ewanmellor> I think we've seen recent instances where things have gone up, and people have objected, and had to come down again.  We should avoid that.  The PPB shouldn't have to veto after the fact.
19:37:38 <jbryce> yes...delegate
19:37:40 <johnpur> i believe we need to have community project management as a defined role, just as we have project release management
19:38:10 <jbryce> johnpur: agreed. and we have stephen in a community manager role right now who does some of these things
19:38:21 <eday> ewanmellor: agreed, and I think this will be fine once we have the process laid out. right now it's just been 'find ant on IRC and ask hime to change DNS', no rules around it
19:38:37 <johnpur> jbryce: operative word is "some".
19:39:13 <ewanmellor> eday: Yes.  Part of this is making sure that Ant and Stephen know that they shouldn't just do something because Joe Random asked them to.
19:39:22 <eday> yup
19:39:33 <ewanmellor> They're being too helpful, which isn't normally a criticism ;-)
19:39:34 <johnpur> ewanmellor: agree
19:39:44 <eday> I think we already have delegates, we just need to let them know whats ok or not :)
19:40:06 <ttx> deciding on a forums system in less than 24 hours, for example, is not.
19:40:09 <vishy> and make sure that the process to contact them is public
19:40:43 <jbryce> vishy: agreed. so i asked todd who has been managing the website to document it in the wiki.
19:40:54 <jbryce> http://wiki.openstack.org/Website
19:41:03 <jbryce> i think we basically need that for the other non-technical things too
19:41:17 <jbryce> and then we need to make sure that they understand some basic ground rules for handing things out
19:42:28 <vishy> jbryce: +1 that all seems reasonable to me
19:42:41 <jbryce> but the reality is that this all doesn't actually fall under what the ppb is supposed to be responsible for. the advisory board has the brand guidelines in their mandate. in the absence of the advisory board existing, though, i think it's fine for us to make some recommendations and encourage the people who are doing this stuff right now to follow some principles
19:43:08 <eday> we just need a comprehensive list and policies around each
19:43:23 <jbryce> i think what we SHOULD define some specific policies around is how projects can make use of the openstack name, brand, logo, domains, etc
19:43:51 <jbryce> as it stands we have 2 designations of projects--related and core--and we want to add a 3rd, incubated
19:43:59 <eday> jbryce: there are some technical issues too, ie, should burrow get jobs on Jenkins? should it get burrow.openstack.org for docs even though it's not a project yet? I ask because I'm sure reddwarf/atlas/etc will want the same soon
19:44:06 <johnpur> i thought the use of the logo, etc. was already defined?
19:44:34 <jbryce> johnpur: to some extent, but not specifically around how projects can use it
19:44:42 <jbryce> related is unofficial, no access to openstack resources
19:45:01 <ttx> jbryce: if we had an openstack foundation, we could have a management board and a technical board. That would hepl in shoving non-technical stuff over the wall :)
19:45:08 <jbryce> ttx: = )
19:45:31 <jbryce> incubated, i would say is an official recognition, you can began to use community infrastructure like jenkins, you can make some use of the brand, but cannot present yourself as an "openstack project"
19:46:06 <jbryce> also, i think incubated projects should live under a single subdomain like incubator.openstack.org or futurestack.openstack.org and inside of a separate launchpad group
19:46:35 <johnpur> ttx: i am suggesting an intermediate step, separating management of the OpenStack project from the technical realities of building the component projects.ing the re
19:46:36 <jbryce> core projects are in the main openstack launchpad group, can have their own subdomains, get full use of the openstack name and brand, their own sections on www.openstack.org, etc.
19:46:51 <eday> jbryce: my issue with that is when the graduate to a real project, links/groups/etc need to change everywhere, and it may be pretty mature
19:47:13 <eday> jbryce: I'd rather have them start in their final place, but with a giant banner or somethings saying it's incubated
19:47:23 <jbryce> good point
19:47:46 <eday> it's easy to drop dns entries if things don't work out :)
19:48:04 <jbryce> then i would say we require some kind of "incubation" badge on whatever is hosted on those subdomains
19:49:41 <jbryce> thoughts?
19:50:10 <ttx> I think that's workable, with the intermediate "incubation" state
19:50:26 <ttx> that allows us to control what gets those resources
19:51:00 <vishy> jbryce: +1 on all points from me
19:51:12 <jbryce> ok...i will collect those designations in a doc and send it around for everyone to review in a little more coherent format
19:51:26 <jbryce> #action jbryce to publish project designations and usage rights
19:51:45 <ttx> you just can't be called "OpenStack Blah" until you get core status
19:51:53 <jbryce> exactly
19:52:01 <ttx> you only live by your code name until then.
19:52:17 <jbryce> #action jbryce to track down community asset managers and get published processes for use
19:52:28 <eday> I guess I need to update burrow :)
19:52:31 <johnpur> there are implications on packaging and distribution as well between core and incubated projects
19:53:13 <ttx> right -- for example it enters the realm of my release management only when it's core.
19:53:22 <johnpur> ttx: correct
19:53:48 <ttx> but my point is that "Burrow" becomes "OpenStack Simple Queue (Burrow)" when it's in core.
19:53:49 <vishy> I think that the goal is to strive to help the incubated projects join the automated packaging and testing systems we have in place, and help make it easy to install them as an add-on to core components
19:55:01 <ttx> next topic ?
19:55:14 <jbryce> we can definitely help them and they should make use of automated systems, but ttx should not be bird-dogging them to get their release out
19:55:19 <johnpur> vishy: agree, but the responsibility is on the project team to produce their packages and make them available
19:55:25 <jbryce> #topic incubation application process
19:55:37 <jbryce> http://wiki.openstack.org/Governance/Proposed/Incubation
19:55:43 <jbryce> http://wiki.openstack.org/Projects/IncubatorApplication
19:56:01 <jbryce> did anyone get a chance to review prior to the meeting?
19:56:40 <ttx> jbryce: maybe add "language" to http://wiki.openstack.org/Projects/IncubatorApplication
19:56:51 <jbryce> good one
19:56:52 <johnpur> jbryce: yes. question on a ppb sponsor?
19:56:58 <jbryce> ok?
19:57:34 <johnpur> what is the responsibility of the sponsor to the incubated project?
19:57:59 <jbryce> your guess is as good as mine
19:58:01 <jbryce> = )
19:58:04 <johnpur> lol
19:58:12 <jbryce> point of contact, helping hand, connect them to the right people to use jenkins
19:58:28 <ttx> an advocate on the PPB ,maybe
19:58:47 <johnpur> does a project need to get a ppb sponsor *prior* to being submitted, ie getting someone to advocate for the new project?
19:58:48 <ttx> though I'd prefer them to present their case directly
19:59:04 <vishy> jbryce: I did, i didn't see anything that i thought needed to be changed
19:59:05 <jbryce> ttx: i like direct access too
19:59:07 <eday> ppb sponsor=SPoF, why not just keep it general?
19:59:21 <ttx> yes, I don't really like the sponsor idea
19:59:54 <ttx> I mean, the PTL for the incubated project might become a PPB regular in a near future, it's good to have him present in the meeting to defend his case ?
20:00:20 <jbryce> it's not about the ppb meetings as much as it is making sure they have a point of contact in the community who can help them find their way around
20:00:38 <johnpur> i don't disagree with the intent, I have been trying to do this for the new RAX projects, anotherjesse has done it for Keystone, etc.
20:00:40 <jbryce> and give them advice and direction on things like...wording announcement emails
20:00:45 <ttx> If they ask for incubation, they should have a pretty good idea who to network with ?
20:01:16 <ttx> I mean, if not as such our desk door was closed all day :)
20:01:22 <ttx> s/if/it's/
20:01:43 <jbryce> i think if it's just general access, they're less likely to reach out
20:02:13 <eday> it seems  wiki page should suffice for most things a PPB sponsor would provide (and if not, just provide an email to the ppb list so anyone can respond)
20:02:55 <ttx> I just don't want a bad sponsor to drown a project -- they should be able to contact any of us
20:03:14 <ttx> and might engage more freely in the absence of a designated person
20:03:25 <jbryce> johnpur: what do you think?
20:03:34 <johnpur> i'm on the fence
20:03:40 <jbryce> me too
20:03:41 <ttx> i.e. the PPb in it's entirety is the sponsor.
20:04:04 <jbryce> i can see that side, but having been involved with some of the groups who are getting started, i think that having someone they are more in direct contact with would be more effective for them
20:04:17 <eday> if we have one, then we need mroe rules around what happens when a PPB drops off before the project goes core. etc
20:04:23 <ttx> I don't really mind either way... just saying that eday has a point with his SpoF comment
20:04:25 <vishy> should we change it to "the project may request a sponsor from the ppb"?
20:04:51 <jbryce> i think the asf actually gives you multiple mentors
20:04:53 <johnpur> i think the role is needed, the new projects have a lot of potential pitfalls they can trip over (as we saw with the RAX proposed projects). They do need guidance from someone who is plugged into the curren state of the project.
20:05:02 <jbryce> maybe that's a better approach
20:05:49 <eday> johnpur: definitely agree, it just seems the entire PPB should provide that role, not just one person.
20:06:32 <ttx> eday: maybe asking everyone to follow the state of every incubated project is a bit too much
20:06:33 <eday> in any event, seems like a pretty minor point
20:06:50 <jbryce> ttx: i concur
20:06:51 <ttx> right, we can try and change if that doesn't work so well
20:06:54 <johnpur> the key point is that the project needs to reach out at the right time, before the bloodletting commences from the outraged villagers :)
20:07:06 <jbryce> haha
20:07:12 <ttx> witch:
20:07:37 <vishy> does the project weigh as much as a duck?
20:07:53 <jbryce> i'm going to change it to may assign one or more mentors for the project
20:08:00 <jbryce> then we can try it out and see how it goes
20:08:02 <johnpur> vishy: exactly!
20:08:08 <ttx> jbryce: +1
20:08:10 <jbryce> eric obviously hasn't needed a mentor or sponsor for burrow
20:08:16 <vishy> jbryce: +1
20:08:18 <jbryce> some projects may need more or less guidance
20:08:28 <johnpur> jbryce: mentor is a much better term than sponsor
20:08:46 <jbryce> ok
20:08:55 <jbryce> this thing is running long...sorry guys
20:08:58 <ttx> next topic, then :)
20:09:03 <eday> do I get one when I apply for incubation? :)
20:09:18 <vishy> eday's mentor is... eday
20:09:20 <jbryce> #topic forums.openstack.org
20:09:28 <jbryce> mentor recursion
20:09:53 * jbryce opens can of worms
20:10:03 <johnpur> jbryce: not exactly true on burrow. we had much conversation prior to starting the project. eday was "sponsored" he just didn't need guidance on the open source community part :)
20:10:20 <jbryce> i honestly am not even sure where we are with the forums.openstack.org issue
20:10:28 <vishy> first question: do we want to make the decision about forums? or do we delegate it?
20:10:29 <eday> we have a Q&A site now on LP. Is it really insufficient?
20:10:54 <ttx> eday: I think it's a bit insufficient, yes.
20:11:06 <vishy> eday: IMO LP Q&A fails in basically every respect
20:11:11 <johnpur> the reality is that a forum site (or 2 or 3) is going to be set up regardless of the official stance the ppb takes.
20:11:17 <ttx> eday: I think if we want to do Q&A, we should do it properly :)
20:11:29 <vishy> eday: no community building, hard to search, no reputation, etc..
20:11:33 <jbryce> johnpur: +1
20:11:39 <jbryce> forums are also different
20:11:40 <eday> ttx: ok, so the consensus seems to be around stackexchange style forums, so lets set one up on forms. and call it good?
20:11:48 <johnpur> the question we need to talk about is how we want the "official" communication channels to be set up
20:11:50 <jbryce> we may not read them or use them but other people will
20:11:51 <vishy> johnpur: I think that is true, so we should probably have an official forum
20:11:56 <jbryce> so the question really is the official nature
20:11:58 <eday> and by this I mean delegate to Jordan :)
20:12:13 <johnpur> eday: or chad keck
20:12:32 <ttx> eday: I think Jordan wants a discussion-oriented forums system. The devs hate that, but kinda like the Q&A-oriented forums systems
20:13:06 <johnpur> ttx: do the devs want to abandon Answers in favor of Q&A?
20:13:06 <jbryce> i have to say that i've heard requests for discussion oriented forums from the non-dev community members as well
20:13:40 <johnpur> PTL's?
20:14:02 <vishy> i would prefer to abandon answers for stackexchange style q&a
20:14:03 <ttx> johnpur: I don't like to talk for everyone -- I'd do, if we were eto use OSQA or StackExchange
20:14:33 <jbryce> it seems like there was general consensus on the list to that approach as well
20:14:36 <vishy> and I'm ok with forums as well, especially if we put a link to the answers site as a sticky :)
20:15:11 <ewanmellor> Could we set up a poll?  It seems like the only way that we'll get an agreement that everyone will live with.
20:15:32 <johnpur> my 2 cents: suggest we transition Answers to OSQA for dev oriecnted discussion, set up "forums.openstack.org" for sysadmin/devops/users. Delegate moderation of the forums to jordan and chad.
20:15:43 <ttx> If we do discussion forums, the devs will ignore them. Maybe that's not too bad. If we do Q&A forums, then the devs would more likely participate to them...
20:15:44 <ewanmellor> It doesn't seem like the devs should care much -- this is a user-to-user thing, isn't it?
20:15:54 <jbryce> the problem is that a poll sent out to the current openstack list will be skewed like the mailing list discussion
20:15:58 <jbryce> ewanmellor: yes
20:16:00 <johnpur> Use OSQA because it is open source and fits with our project values.
20:16:13 <jbryce> i'm fine with johnpur's proposal
20:16:33 <ewanmellor> jbryce: No, the mailing list discussion is full of mad screaming.  A poll would be out of my way and much quieter!
20:16:51 <jbryce> ewanmellor: good point!
20:17:03 <vishy> FWIW, we got denied by stackexchange, so osqa!
20:17:11 <johnpur> i think this is an area we can exert a little community leadership
20:17:15 <ewanmellor> jbryce: And I think that if we did a poll, and left it up for a week, say, then everyone has plenty of time to make a decision.
20:17:30 <vishy> johnpur +1
20:17:38 <ttx> I'm ok with johnpur's suggestion, though I would not rush the OSQA transition. We are not in a hurry, I think
20:17:49 <vishy> people can always link from forums to QA
20:17:55 <johnpur> ttx: agree
20:17:57 <jbryce> ok...so forums.openstack.org becomes discussion forums
20:17:59 <ttx> That's dilution, but I guess we can live with that
20:18:08 <ewanmellor> Wouldn't the right open source thing be to write our own forum software from scratch, because we're smart and can do it better than everyone else?
20:18:10 <jbryce> jordan and chad and others can moderate
20:18:18 <ttx> ewanmellor: we are indeed !
20:18:31 <jbryce> and then we will move questions to OSQA at some point?
20:18:35 <jbryce> is that where we've landed?
20:18:47 <johnpur> jbryce: +1
20:18:54 <vishy> ewanmellor: +1 OpenStack Forums (code name NIH)
20:18:58 <ttx> having a Q&A system should limit people asking technical questions on the discussions site.
20:19:43 <ewanmellor> Did you just make a decision on this with a consensus of three people?
20:20:40 <jbryce> i think it was actually only 2
20:20:47 <ttx> haha
20:20:47 <jbryce> no decision was made
20:20:51 <vishy> ewanmellor: what would the options on the poll be?  I'm not sure if it will solve anything?
20:20:53 <johnpur> ewanmellor: good point... ppb members please vote... now.
20:21:22 <ttx> +0
20:21:23 <ewanmellor> I think, given that there are emails coming in about this even now, that us making a decision would be heavy-handed.
20:21:56 <ttx> ewanmellor: you mean we could let more time pass for discussion before making that decision ?
20:22:02 <johnpur> i think the emails are rehashing and posturing. i havent seen a new argument today.
20:22:03 <jbryce> there are going to be forums...the question is really do they get to use forums.openstack.org
20:22:04 <ttx> I'd fully support that
20:22:18 <ewanmellor> Poll options would be: OSQA, the three least horrible web-BBS technologies, and stay with Launchpad.
20:22:19 <vishy> I think going with both will make 95% of people happy
20:23:14 <jbryce> ewanmellor: i think one of the problems is that somehow this got pushed into our lap and we were supposed to have a stance on it today
20:23:23 <johnpur> 95% is above our target goal of 92%.
20:23:32 <alekibango> ewanmellor: which web-bbs technologies are not horrible? lol
20:23:36 <ttx> jbryce: we can decide to decide next week, though.
20:23:59 <ewanmellor> ttx: +1
20:24:02 <vishy> someone is going to make a forum anyway...
20:24:06 <jbryce> exactly
20:24:06 <vishy> :)
20:24:12 <johnpur> ttx: my view is that waiting is not going to change the outcome.
20:24:24 <alekibango> johnpur: +1
20:24:26 * ttx is returning to his well-deserved vacation time in ~6 minutes.
20:24:32 <jbryce> i don't think the list discussion is going to result in agreement
20:24:39 <ttx> so I'll stop arguing :)
20:24:44 <ewanmellor> jbryce: I agree with that!
20:24:59 * johnpur wants to be ttx and on vacation
20:25:15 <jbryce> let's take an actual vote and see if we're just completely deadlocked here, then we can push it back.
20:25:37 <ewanmellor> -0: Don't care enough to veto.
20:25:41 <jbryce> who thinks we should recommend that some piece of discussion forum software gets to live forums.openstack.org
20:25:43 <ttx> +0
20:25:50 <vishy> +1
20:25:51 <johnpur> +1
20:25:55 <jbryce> +1
20:25:57 <eday> +1
20:26:09 <ewanmellor> +1 for whatever it is appearing on forums.openstack.org.  That's fine.
20:26:25 <jbryce> ok
20:26:37 <alekibango> + 0.1 (... i am not in PPB:)
20:26:40 <jbryce> i think we're all running low on gas
20:26:50 <jbryce> this has been another marathon meeting
20:26:51 <alekibango> would be 1
20:26:55 <ttx> could we push the last item to next week ?
20:26:57 <eday> lets put it on it's own VM though, when it gets hacked, I don't want the other domains to go down :)
20:27:02 <jbryce> ttx: yes
20:27:10 <jbryce> sorry for bleeding into more of your vacation time
20:27:11 <ttx> eday: +1000
20:27:12 <JordanRinke> Can forums.openstack.org delegate out to Stephen and me to work out with the commmunity what bbs goes there?
20:27:28 <ttx> jbryce: my fault, I could have ignored it completely :)
20:27:40 <jbryce> well add an extra 1.5 hours on the end
20:27:57 <johnpur> Jordan: work with Chad Keck as well.
20:27:59 <eday> JordanRinke: sounds good to me
20:28:00 <jbryce> JordanRinke: i have no desire to dictate forum software
20:28:11 <ttx> JordanRinke: no problem with that.
20:28:14 <JordanRinke> Excellent, thx all
20:28:33 <jbryce> let's end this thing
20:28:34 <jbryce> thank you guys!
20:28:37 <eday> yay for delegation!
20:28:41 <ewanmellor> ttfn
20:28:58 <jbryce> #endmeeting