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?
Minutes
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.