MapGuide PSC Meeting 11-02-2006

MapGuide PSC - Home

Meeting Info
The third meeting of the MapGuide PSC will take place Thursday November 2nd at 17:00 UTC (1:00 PM EST / 11:00 AM MST / 10:00 AM PST).

Meeting Chair: Bob Bray Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=2&year=2006&hour=18&min=0&sec=0&p1=0 Location: The meeting will be held on IRC at #mapguide

Agenda

 * RFC Process Discussion (let's try and close off the e-mail threads)
 * Road Map / Release Schedule Discussion
 * Quick clarification of eVote and IRC veto process
 * If no timeline specified on eVote, 1 week default? Or 48 hours default, 1 week specified if needed?
 * Can we extend IRC veto to 48 hours to allow entire globe time for response?

IRC Log
jasonbirch	Ding -->|	zool (n=jo@tridity.org) has joined #mapguide rbray	Ah there is the bell, must be that time. jasonbirch	:) Andy	I'm suddenly hungry (Pavlov) zool	sorry i can't resist eavesdropping, but i'm just lurking ;) rbray	Looks like we are missing Paul at the moment. rbray	zool: No worries. jasonbirch	No, I like the idea of a fan club ;) rbray	Let's go ahead and start without Paul, I am sure he'll join at some point. -->|	TomFukushima (n=chatzill@adeskout.autodesk.com) has joined #mapguide rbray	Based on the e-mail response, I'll kill the PSC mailing list today. So please start using the dev list. jasonbirch	Probably late getting back from lunch. Oh wait, he's a coder. They don't take meal breaks... jasonbirch	Tom hasn't voted yet... Do we require full response to eVotes? rbray	no, we have more than enough votes to make that officiial. jasonbirch	Never mind, I'm slow bdechant	Tom did vote - about 10 mins ago. :) TomFukushima	Yes, sorry I was being lazy about that vote jasonbirch	I'm a bit confiused on voting standards. Have to go back and read the main page. rbray	The first agenda topic is one I know Paul is interested in, so lets start at the end of the agenda and work our way up. rbray	Well the first topic is voting, so lets clarify it now. zjames	rbray: Paul is in meetings all afternoon, unfortunately. rbray	All motions should have a timeline associatied with them in my mind. I thought I put that in the guidelines. rbray	zjames: thanks. jasonbirch	Right now we don't differentiate between process and RFC votes. rbray	Right a vote is a vote. jasonbirch	Should I have filled out an RFC instead of making a motion? rbray	No a motion for stuff like that is fine. rbray	In my mind. It was just a small process change and the PSC doc has not been approved/finalized yet. Andy	Doesn't an RFC pertain only to software changes within the project and not process? jasonbirch	you said "a deadline of at least two working days and preferably one week must be given" so I messed up rbray	Right :) rbray	I thought I had that in there. jasonbirch	Can we set a default of 48 hours for motions, and 1 week for RFCs? rbray	Andy: RFCs can pertain to both software and process. rbray	When they are required is one of the things we will need to work out over time. rbray	I think once the PSC doc is finally and approved for example, an RFC should be required to change it. jasonbirch	rbray: agreed. We will have a motion to adopt at some point. rbray	Hopefully by the end of this week or early next actually. I got some good feedback from the FDO PSC, and plan another round of changes. rbray	For highlights see the meeting minutes. jasonbirch	Uh, I think that we should be involved in that; we want the projects to evolve independantly. jasonbirch	But together :) rbray	It included the last item on todays agenda, moving veto grace to 48 hours. rbray	Yes we do. That is why I will send a mail to this PSC with the recommended changes before I make them. rbray	Just have not had the time. jasonbirch	Currently, I think that we require the entire vote time to elapse unless everyone votes, because we have the veto option. Is that correct? rbray	Yes. Votes are counted at the end of the specified period, unless we have 100% majority earlier. rbray	In this case you did not specify a duration, but we got majority anyway. rbray	100% with Toms jasonbirch	fullality :) rbray	Is that in the dictionary? jasonbirch	I'd like to see a default 48 hours for mothions 1 week for RFCs, because I'll mess up again. It's in my dictionary jasonbirch	(Jason's Unabridged and Unorthodox) rbray	Hmm, I think this is where we have some confusion. rbray	RFCs should be discussed first, then be brought forward for vote via a motion. jasonbirch	true. jasonbirch	sorry rbray	So you want RFC based motions to be 1 week? rbray	Seems long to me if we have already discussed them. jasonbirch	By Default. The motion should specify less if it's an easy one? jasonbirch	Hmm. That makes sens. TomFukushima	Yes, I'm getting the developers here to put out RFCs that are not completely filled in, in case better ideas come in. Is it 1 week from when the incomplete RFC was posted, or after the final RFC is posted. jasonbirch	Who makes the motion? Does an RFC need a PSC sponsor? jasonbirch	It's one week from when a PSC sponsor makes a motion to adopt. jasonbirch	But I think that 48 hours makes more sense for items that already have agreement on the mailing list. rbray	I think the doc says anyone can make a motion. Let me check. TomFukushima	Yes, I would prefer 48 hours. rbray	Ah, it does not say. So do motions need to be made by a PSC member? Developer? or Anyone? jasonbirch	That's anarchy. :) You say that anyone can make a proposal, but I think that motions should only be made by members of the committee. rbray	I was hoping you would say that. jasonbirch	Convincing one of us to make a motion shouldn't be that high a barrier... rbray	So proposals and RFCs can be brought forward by anyone, but a motion to approve must be made by a PSC Member. rbray	Everyone agree? jasonbirch	+1 Andy	+1 Haris	+1 bdechant	+1 TomFukushima	+1 jasonbirch	I guess you're a +1 bob? Can we also agree to a 48 hour default timeline?	rbray	Yes I am +1	rbray	I would agree to that. +1	TomFukushima	48 hour default timeline, but only if the RFC has been previously discussed on the mailing lists	rbray	Unless the motion expressly states different, the voting is held open for 48 hours.	jasonbirch	I for one won't bring a motion without the RFC previously being discussed.	jasonbirch	They need one week after proposal before the motion anyway... rbray	RFCs probably should not be brought to motion until they are discussed. We should clarify that too. rbray	One week is good. jasonbirch	(I think it's already clarified in the current doc) TomFukushima	oops, I better reread the doc rbray	Yea, but we are sitting here discussing it, so maybe the doc is not as clear as it could be. rbray	Actually I just re-read it. Clear as mud. jasonbirch	I think that we should produce a trimmed down "working" version after adopting the full contents as our bible. jasonbirch	Like the working RFC doc. rbray	Yes as we discussed on the list an RFC page would be a really good start. rbray	So are we cool on voting. Any other clarifications required? jasonbirch	Can we vote on 48 hours and move on? TomFukushima	+1 Andy	+1 rbray	+1 bdechant	+1 jasonbirch	+1 Haris	0 rbray	Ok, passed. Unless of course Paul vetos. jasonbirch	And it's totally OK to vote -1 if you need time to think rbray	Yes don't let me bully. jasonbirch	I mean in the general process Haris	i really not sure, 48 hours after discussed on emails ? jasonbirch	If 48 hours is too short for, for instance, Haris :) 48 hours after motion is brought.	rbray	To me the early discussion is more of a way to flush out the RFC.	Haris	I am not sure what means "disccussed", after first reply ?	rbray	Work out the kinks and understand the implications of the change.	rbray	Once that is all worked out, then the motion and voting are more a formality.	rbray	Assuming everyone generally agrees with the RFC	Haris	ok, i am 0 on that :) jasonbirch	For RFC's a motion can be brought any time beyond one week after when the proposal is made to the DEV list. That motion has a default expiry of 48 hours. rbray	Harris: we are of course open to alternative suggestions as well Haris	yes, one week i do agree and understand Haris	no, it is ok, just not sure when this 48 would start, but i am not against rbray	The 48 starts when the motion for a vote is first made. rbray	So whenever that e-mail is sent jasonbirch	Ah. Does the 48 hours start after the motion has a seconder? Do we need a seconder? rbray	Yes a second should be required, and no I think it starts with the motion. jasonbirch	(I hate process, but I think we need to clarify it now) Haris	yes sorry, i meant that something was discussed, what is def of that, but really we can skip that jasonbirch	If it isn't adequately discussed to your likings, vote -1 on the motion and send it back. Haris	yes rbray	How about I draft up this stuff and fire off an e-mail for feedback. If we all agree I'll update the document and make a motion to accept it. jasonbirch	Sounds good to me. rbray	Ok, give me till the weekend though to get the first e-mail out. jasonbirch	I think I heard some agreement on the list about the RFC process, and I personally think that the current template is reasonable. Kinder gentler will go into a separate document. rbray	The other processs item is extending the IRC veto time to 48 hours to accomodate timezones. This was first brought up in the FDO PSC meeting. rbray	I am personally +1. Haris	+1 Andy	+1 bdechant	+1 TomFukushima	rbray: For draft: Can you mention something about the RFC being frozen during the 48 hours? I don't think changes should be allowed in that time. TomFukushima	+1 rbray	jasonbirch: Lets go on to RFC next. rbray	TomF: Yes, good idea. jasonbirch	+1 (sorry IRC has some drawbacks like no flashing light) rbray	Hey you are supposed to be in this meeting not checking e-mail :)	rbray	So on to RFC Process. Jason I liked your suggestion on e-mail and think we are all more or less on board.	rbray	An RFC page to discuss the process similar to your proposed text.	jasonbirch	But our main PSC page being 'da rulez'	rbray	When filed they are out for discussion and feedback, not approval.	rbray	jasonbirch: yes	rbray	once they iterate on dev and gel, a PSC sponsor can motion.	jasonbirch	I think that the default 1 week is good, and if we need more that can be communicated when/before the motion is made.	rbray	Yep, the one week can always be extended if discussion is ongoing.	jasonbirch	I'm happy to sign off on that process, if you want to include in your email anon	rbray	OK	rbray	I think Paul would agree as well, but we'll find out when i send the e-mail.	jasonbirch	Can we move on to roadmap?	rbray	Yep rbray	You mean my 5 minute roadmap? jasonbirch	I think that the document should have a status flag of pending, and that once the currently underway work gets complete, only adopted RFC items should be slotted into the roadmap. jasonbirch	Sorry, the items in the document. rbray	Yes I agree. I just wanted to put something rough out there for folks to shoot at. jasonbirch	Understood rbray	And I can't wait to get a real CMS to make some of this easier. jasonbirch	Wiki isn't too bad; maybe we should just use the Trac wiki for the project docs. Andy	Are we talking about the actual items in the roadmap or the structure of it? jasonbirch	Structure I think. Items need to go through RFC rbray	Yea structure and format. jasonbirch	I like the items I see though, although some don't scratch my personal itches. Andy	OK, I have a comment on the items that I'll take offline with Tom and Bob. jasonbirch	We need to maintain a spearate wishlist, probably through a bug status eventually. rbray	Agreed. rbray	So should I redraft that to reference the RFCs? rbray	But then do I delete stuff without an RFC? jasonbirch	Create a dummy RFC for those items, like the other dummy RFCs rbray	I was trying to give you an idea of where ADSK was headed in the short/medium term; Haris	yes and no rbray	jasonbirch: that is a good idea. rbray	With a release target in the RFC. jasonbirch	With a proposed release target in the RFC rbray	Yea that is what I meant. rbray	Sorry jasonbirch	Another item for the Status area. rbray	yes it should be up front i think. jasonbirch	That can be a living document, but I'm happy with the current contents + target release. rbray	me too. jasonbirch	We should have a revision ID on the template though. rbray	yes another good idea. jasonbirch	I'll add that and the proposed release target to the template after the meeting. rbray	What about the roadmap format. Releases with rough dates. rbray	jasonbirch: thanks rbray	A theme if available rbray	And a list of RFCs? rbray	What else? jasonbirch	Theme? I think the roadmap fits well with the release process document, which I also agree with. jasonbirch	Is theme an overarching concept, then individual RFCs within that theme? jasonbirch	Oh, we're running down on time. I can see Bob's clock ticking :)	rbray	Yep	rbray	Theme was just a way to group things / describe a release.	rbray	Maybe we don't need it	jasonbirch	I like the theme idea, it makes the release more approachable by outsiders.	jasonbirch	Makes it easier to write the press release too.	rbray	Yes it's really an internal idea I was trying to bring to the open source world.	jasonbirch	Does anyone have any issues with the road map or the release process as they currently stand? I didn't see much discussion on the lists?	jasonbirch	Can we vote to adopt them as current working versions then?	rbray	Or at least the December and April/May targets.	Andy	Are we talking items now then (targets)?	rbray	No i meant dates.	Andy	Or just general timeframe?	Andy	Thanks	rbray	RFCs will define the actual features.	Andy	I'm starting to get that......	rbray	I'll be on after so you can ask your item questions.	jasonbirch	Dates/process are good. Vote vote vote. +1	rbray	+1 Haris	+1 bdechant	+1 TomFukushima	+1 Andy	Agreed. If Autodesk thinks those times are good to start then +1 rbray	Thanks we really need to get 1.1 out on FDO 3.2. That is my main objective of the December release. jasonbirch	If they don't they can always fork development :)	rbray	NO FORKS HERE	jasonbirch	spoon then...	jasonbirch	Adjourn?	rbray	Ok, so we are out of time. Any closing thoughts?	rbray	Then yes. let's adjourn. Thanks everyone.	jasonbirch	+1, thanks.