Difference between revisions of "MapGuide PSC Meeting 10-19-2006"

From OSGeo
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[MapGuide PSC]] - Home
 +
 
== Meeting Info ==
 
== Meeting Info ==
−
The first meeting of the MapGuide PSC will take place Thursday October 19 at 1:00 PM EST / 11:00 AM MST / 10:00 AM PST.
 
  
−
The meeting will be held on IRC at irc://irc.freenode.net/#mapguide.
+
The first meeting of the MapGuide PSC will take place Thursday October 19 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=10&day=19&year=2006&hour=17&min=0&sec=0&p1=0
 +
Location:  The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide]
  
 
For IRC newbies Chatzilla is probably the best way to get going. It works with Firefox and once installed you can log onto the channel by pointing your browser at: irc://irc.freenode.net/#mapguide. You can download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.
 
For IRC newbies Chatzilla is probably the best way to get going. It works with Firefox and once installed you can log onto the channel by pointing your browser at: irc://irc.freenode.net/#mapguide. You can download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.
Line 8: Line 13:
 
== Agenda ==
 
== Agenda ==
 
* Review PSC Document - https://mapguide.osgeo.org/psc.html
 
* Review PSC Document - https://mapguide.osgeo.org/psc.html
 +
* Scheduling IRC Meetings PSC and Development
 
* Initial PSC Size and Nominations
 
* Initial PSC Size and Nominations
−
* IRC Meetings PSC and Development
 
 
* Future of the PSC mailing list
 
* Future of the PSC mailing list
 +
 +
== Minutes ==
 +
 +
=== Agreement on ===
 +
 +
* Voting primarily by email, following guidelines on PSC page
 +
* IRC voting allowed with 2/3 quorum (what's 2/3 of 7?) but members unable to attend can veto within 24 hours of posting/emailing of minutes
 +
* All technical decisions floated to DEV list. Final decisions and other process items made by PSC on PSC list.
 +
* meetings to be held weekly at this time until boostrapping complete.  Will eventually be only held as required with email being preferred .
 +
* DEV to meet weekly by IRC.  Developer members of PSC expected to attend DEV meetings (non-developers welcome).  DEV meetings will not start up until we get a bit further into the boot process.  Like to the second L in LILO.
 +
* meeting minutes to be emailed and posted after meetings
 +
* PSC will be brought up to 7 at next meeting.  Expansion considered after a month.
 +
 +
 +
=== Actions ===
 +
 +
Bob to:
 +
* Update PSC document based on feedback
 +
* Post an initial straw-man roadmap based on current ADSK plans
 +
 +
All to:
 +
* think about how to fill 7th PSC role.  Bring nominations to next meeting for vote.  Requirements / desirables:  Non-ADSK, not north-american, active on mailing list.  Jason would prefer a developer. (guess who's writing the minutes)
 +
 +
=== Carry Forwards ===
 +
 +
* Create template for change requests
 +
* Evaluate expansion of PSC in one month
 +
* Vote for 7th initial member
 +
 +
 +
=== IRC Log ===
 +
 +
(edited for clarity.  original posted to psc at mapguide.osgeo.org mailing list by Paul, though it doesn't appear to have shown up in the archive yet.  Let Jason know if you want a copy)
 +
 +
brayr : Welcome
 +
jasonbirch : Thanks. Is there a logging service for #mapguide? Perhaps qgis could help?
 +
brayr : No not at the moment. That is one of the things we need to sort out. Logging.
 +
brayr : I am an IRC newbie, so help would be appreciated.
 +
brayr : Looks like everyone is here. So let's start with the first item on the agenda.
 +
brayr : I did not get to make another pass at the document this morning (as you probably noticed).
 +
brayr : There was a couple of things in the e-mails I want to work in.
 +
brayr : First is the PSCs responsibility for defining a RoadMap. (thanks Jason)
 +
brayr : My thinking is that the roadmap would help guide some of the feature decisions. Thoughts?
 +
pagameba : I agree
 +
jasonbirch : Agreed. Obviously, Autodesk has some plans for the product. Can we see those plans and use to help bootsttrap our roadmap?
 +
Andy_Morsell : Would this be more high-level, or very feature specific? Didn't Sean Sternfeldt start something that is still posted on the Wiki?
 +
jasonbirch : That's a wishlist. Diffferent beast.
 +
brayr : yes, we can certainly bootstrap the process with our internal roadmap. But I would really lilke this group to take some ownership and supply input.
 +
brayr : input
 +
jasonbirch : not just input, control. Control Control (sorry, got carried away)
 +
pagameba : How specific do you see the road map being?
 +
brayr : yes that is really what I meant.
 +
pagameba : and will we use the roadmap to seek contributions (funding, code etc)
 +
brayr : Long term roadmaps tend to be theme driven. Short term, e.g next release are more specific.
 +
brayr : Yes
 +
pagameba : ok
 +
jasonbirch : I think there are two categories. Architectural change, and feature implementation. Big features should be in roadmap
 +
brayr : Yes, roadmaps are about big features. Things like Geocoding, or WCS, or ...
 +
jasonbirch : Do changes drive architecture, or do we identify inefficiencies and do architectural change as features when required?
 +
brayr : Could be both.
 +
brayr : I think at this point, architecture is mostly feature driven.
 +
brayr : But there may come a day when that is not true.
 +
brayr : So I'll draft a section on roadmap and then we can iteratate.
 +
jasonbirch : Sounds great.
 +
brayr : Another item in the doc is Process.
 +
jasonbirch : Out of left field... Version numbers. 1.1 is development, 1.2 is release, etc?
 +
brayr : The doc did not clarify if decisions are made and voted on at a meeting like this or the mailing list.
 +
brayr : NO
 +
brayr : I really do not like the even odd thing. Let's table that for a future meeting and we can sort it out.
 +
jasonbirch : OK.
 +
jasonbirch : Do we need quorum? If not, email vote should be fine.
 +
Andy_Morsell : It seems like voting via mail list would be the best as not everyone will always be able to attend each meeting.
 +
brayr : So do we want all decisions made in an IRC meeting or via e-mail, or leave it open for both
 +
brayr : I like e-mail because of timezones, travel, etc.
 +
jasonbirch : And because of lasting record. But that shouldn't prevent us frmo making decisions in IRC
 +
pagameba : it is sometimes more efficient to do it in an IRC meeting ... how about ...
 +
pagameba : if we have a quorum at a meeting (2/3) then we can make a decision
 +
jasonbirch : Sounds reasonable to me.
 +
brayr : That makes sense.
 +
Andy_Morsell : Sounds reasonable
 +
pagameba : but there is an opportunity for the non-participants to veto within x days
 +
jasonbirch : 24 hours so we don't get surprised.
 +
brayr : Yea, it needs to be pretty short.
 +
jasonbirch : after putting in lots of work
 +
brayr : Any decision made in IRC needs to be broadcast via e-mail.
 +
brayr : 24 hours from the e-mail seems right.
 +
pagameba : I like it
 +
jasonbirch : I think that the email should be a courtesy, and official from posting of minutes.
 +
jasonbirch : Email is not all that reliable, so members need to take responsibility to check minutes.
 +
brayr : yea that is fine. But I know many people read minutes in spare cycles, but e-mail regularly.
 +
brayr : Its the old push / pull thing
 +
Andy_Morsell : I would like to see minutes emailed and posted
 +
pagameba : I have another process question
 +
jasonbirch : Agreed, but it pervents the "I never got that email" argument. Agreed Andy.
 +
brayr : Yea I like Andy's suggestion.
 +
brayr : Ok, I'll draft that in as well.
 +
brayr : Ask away Paul.
 +
pagameba : MapServer has a TSC as opposed to a PSC ..
 +
pagameba : it makes technical decisions
 +
brayr : They are moving to a PSC. Is that correct Daniel?
 +
pagameba : should we have the concept of a TSC that includes all committers
 +
brayr : I am not sure they intend to keep the TSC.
 +
jasonbirch : That's just elitist bunk (grin) I want to be involved in technical decisions even though I'm not a developer
 +
pagameba : PSC + committers
 +
brayr : The real question here is "does the commiter community get a vote"
 +
pagameba : I'm just thinking that committers may have some valid input/concerns over purely technical issues that currently the PSC would vote on
 +
jasonbirch : I think that we should be able to refer items to the dev@ list for discussion, but retain final decision.
 +
pagameba : yes, exactly !!!
 +
brayr : Well here is a good question. Should the PSC mailing list go away, and all PSC communication happen on dev?
 +
jasonbirch : Or, all technical discussion on the dev list, and process on psc
 +
brayr : Could do
 +
jasonbirch : separate functions. I think anyway.
 +
pagameba : I'm worried that Jason will push for things that are hard to do ;)
 +
jasonbirch : Lol, bad experiences Paul?
 +
pagameba : lol ... no, I swear!
 +
brayr : That is the role of a user in the PSC IMO
 +
brayr : To push
 +
pagameba : I like having separate lists
 +
brayr : Or part of the role anyway. Also to bring balance and end user perspective to decisions
 +
danmo : sorry for the delayed answer... yes the MapServer PSC will *replace* the TSC.
 +
jasonbirch : Let's keep em separated. (hmmm, now I have a song stuck in my head)
 +
brayr : Thanks Daniel!
 +
Andy_Morsell : Separate lists. I have not participated in the dev list to date, but will obviously have to at least start reading the messages.
 +
pagameba : ok ... I would be happy if the process document says that the PSC advertises for comments on the dev list prior to making a decision
 +
jasonbirch : Not much activity yet.
 +
brayr : OK so Process on PSC, development of features, technical stuff on DEV
 +
Andy_Morsell : Jason - a closet Offspring fan?
 +
jasonbirch : Fraid so.
 +
brayr : Yes I would agree. Any technical item, feature request, etc gets floated on DEV
 +
jasonbirch : Sounds good. Do we have to vote? :)
 +
pagameba : +!
 +
brayr : My concern is that we will see a lot of cross postings.
 +
pagameba : +1
 +
brayr : +! is that a new type of dictorial decision?
 +
pagameba : lol
 +
jasonbirch : it's an override :)
 +
brayr : Yes lets vote on that. DEV for technical, PSC for process. All technical stuff gets floated on DEV.
 +
brayr : +1
 +
jasonbirch : +1
 +
TomF : +1
 +
bdechant : +1
 +
Andy_Morsell : +1
 +
brayr : Done. I'll draft that in as well.
 +
jasonbirch : The dev list has been pretty quiet. Will that change asn this moves to be more of a community project?
 +
brayr : Yes. It is quiet IMO because ADSK does most development. That has to change
 +
danmo : danmo just joined the -dev list and didn't see much activity yet, but I think -dev becoming more alive will be a requirement for graduation from OSGeo incubation
 +
brayr : That makes sense.
 +
pagameba : The various project tracking lists are reasonably busy :)
 +
jasonbirch : Bob, will all Autodesk developers be encouraged/allowed to take a community role, or will they be in a contracted employee role?
 +
brayr : Any objection to me moving the addition and remoaval of members to the process section. Similar to MapServer TSC/PSC doc?
 +
jasonbirch : No objection
 +
pagameba : no
 +
Andy_Morsell : No objection
 +
brayr : They will be encouraged to take a community type of role.
 +
brayr : All ADSK development will be floated via RFC and discussed in dev.
 +
pagameba : like Traian :)
 +
brayr : yea
 +
jasonbirch : lol
 +
brayr : Let me just say it is not easy to break old habits.
 +
brayr : OK, I will move the addition/removal of members to Process.
 +
pagameba : for RFCs is there a format?
 +
jasonbirch : We need to work on one, with suggested elements, etc.
 +
brayr : We need to create one.
 +
brayr : yea
 +
brayr : Let's get this doc settled first. Then move on to that. We should make a list on the Wiki of things to do.
 +
jasonbirch : Let's spend some time on that in the interim and flesh it out at next week's meeting (I won't be here)
 +
brayr : Nice
 +
Andy_Morsell : Is this the regular day and time for the meeting then?
 +
brayr : That is next on the agenda. Meetings.
 +
brayr : Anything else on the document before we move on?
 +
Andy_Morsell : Sorry to jump ahead......
 +
brayr : Np
 +
brayr : Going once.
 +
jasonbirch : I'm happy with the doc. Weekly meetings always going to be required, or weekly to start and then biweekly? If we don't have to make decisions in meetings...
 +
brayr : Ok, I'll update the doc and we'll discuss/approve on the mailing list.
 +
brayr : That is the first question. How often should the PSC meet?
 +
brayr : On IRC that is
 +
Andy_Morsell : Is every two weeks not enough?
 +
brayr : I propose weekly or bi-weeekly until we get things running, then we decide.
 +
jasonbirch : I think that biweekly should be fine, especially since decisions can and generally will be made via email. But weekly for the first month or so.
 +
brayr : +1
 +
Andy_Morsell : +1
 +
jasonbirch : I have to jump through major hoops to get on IRC from work, so can't always be tuned in. Prefer email.
 +
jasonbirch : +1
 +
pagameba : +1
 +
bdechant : +1
 +
brayr : I prefer e-mail as well, so long term I would prefer we mostly operate by e-mail. This is bootstrap time.
 +
brayr : Now for a bigger question. What about DEV meetings.
 +
brayr : Should dev meet weekly by IRC?
 +
pagameba : being a developer, I would say yes :)
 +
brayr : Might force more of an open communication than we are seeing now.
 +
TomF : yeah, I prefer email
 +
jasonbirch : Do you have any problems with corporate firewall Bob?
 +
brayr : No
 +
Andy_Morsell : I agree. But, would it be expected for PSC members to attend each? Or would reviewing the DEV minutes be sufficent? I'm having trouble understanding where the roles overlap.
 +
brayr : e-mail would be fine, but again we are just not using DEV today as much as we should be.
 +
jasonbirch : I don't think that it should be required for PSC to participate in DEV. Just know what's going on enough to vote and guide development of features they have voted on.
 +
brayr : Good question. I think PSC members who are commiters would have to attend the dev meeting.
 +
brayr : Other PSC members optional/
 +
jasonbirch : 2 daytime meetings a week might be a bit of a burden...
 +
Andy_Morsell : OK. But, part of our decisions are based on the DEV discussions and that would only come during the formal change submittal process?
 +
brayr : yes.
 +
jasonbirch : Yes, we will take guidance from DEV of feasibility, but changes will come through process.
 +
brayr : I agree 2 meetings is a lot, but the PSC one will go away I think.
 +
Andy_Morsell : Thanks for the clarification. In case you hadn't noticed, I'm a bit new to this.
 +
brayr : You are not the only one.
 +
jasonbirch : Yes, at some point PSC IRC as required only.
 +
jasonbirch : Yikes, I think we're on schedule...
 +
brayr : yea, so it is really one meeting. The issue I have with IRC is more around timezones. It's hard to get good world-wide involvement via IRC.
 +
brayr : Let's try a couple of dev meetings and see how they go.
 +
jasonbirch : After we get the roadmap?
 +
brayr : Some of this will be an iterative learning process.
 +
jasonbirch : And maybe some techincal feature requests?
 +
jasonbirch : Need to have something to meet ABOUT
 +
brayr : yea, I don't think starting now makes much sense.
 +
brayr : So does this time work for everyone? For the initial PSC meetings anyway?
 +
pagameba : +1
 +
jasonbirch : +1
 +
bdechant : +1
 +
Andy_Morsell : +1
 +
TomF : +1
 +
brayr : Ok, next topic. Initial PSC size.
 +
jasonbirch : The voting structure doesn't require tie breakers.
 +
brayr : We are at 6, need a seventh. Should we go straight to 9?
 +
jasonbirch : Why seven?
 +
brayr : I like odd numbers, just in case we all vote.
 +
brayr : It is not strictly required.
 +
Andy_Morsell : I like 7
 +
jasonbirch : I think we should see where the project goes and keep it small at first. That allows merit-based expansion. Unless you have someone in mind?
 +
danmo : I would tend to agree with jasonbirch on keeping room for adding people once the project gets going
 +
brayr : I have one nomination in mind. I also would like some non North American input/involvement.
 +
jasonbirch : Good idea. Is +1 enough for now, and a commitment to add two more before leaving incubation?
 +
brayr : I don't even know that we need one or two more before leaving. MapBuilder is seven I think.
 +
brayr : But +1 for now seems right to me.
 +
danmo : pagameba: is there minimum PSC size required by incubation? I personally think that 7 should be enough
 +
pagameba : there is not a minimum required
 +
brayr : Any nominations out there?
 +
pagameba : smaller is better for actually achieving concensus
 +
jasonbirch : I guess what I meant, is 1 enough for your desired global inclusion Bob?
 +
brayr : No0
 +
brayr : But it could be.
 +
pagameba : who do you have in mind, Bob?
 +
brayr : I am fine to stay small ongoing. Like no more than 9.
 +
brayr : Traian.
 +
Andy_Morsell : Any more than 9 and it starts getting unmanagable
 +
danmo : Is Traian with ADSK? And how many ADSK people would that make on the PSC?
 +
brayr : His input, involvement, and code contribution are huge. At ADSK he now longer works on the project, nut has stayed involved.
 +
danmo : (not objecting, just wondering at this point)
 +
brayr : nut = but
 +
Andy_Morsell : Well, get him back on the project! ;)
 +
pagameba : +1
 +
brayr : danmo: You hit one of my concerns on the head.
 +
pagameba : :)
 +
pagameba : what about including an FDO person?
 +
jasonbirch : I personally feel that Traian would be a GREAT addition. There would be 4 ADSK on the committee at that point.
 +
brayr : That would make the PSC ADSK, three external.
 +
pagameba : like Haris?
 +
jasonbirch : Or Mateusz
 +
pagameba : Haris has expressed interest in doing some WebStudio stuff
 +
brayr : Haris would be a good addition. I plan to nominate him for the FDO PSC.
 +
pagameba : :)
 +
pagameba : Perhaps because of the close ties, we should plan for 1 member to be on both ...
 +
brayr : There are a couple others on the mailing list as well that are very active users.
 +
Andy_Morsell : Haris would be good. He's obviously extremely smart. Yes, maybe more suitable for the FDO PSC.
 +
jasonbirch : If he's interested in MapGuide it would be great to have non ADSK liason between the two as well
 +
brayr : Yes. Right now I am the only liason.
 +
Andy_Morsell : Good point Jason
 +
jasonbirch : Need to be joined at the mind as well as the hip :)
 +
pagameba : So we have Mateusz, Haris and Traian as possibilities, plus potential from the user's list
 +
danmo : I think that with respect to incubation and for the appearance of independance from ADSK, you should not add more ADSK people at this point... that would definitely help prevent any objections when time comes to graduate from incubation
 +
brayr : We are just about out of time. Let's table this and discuss agian next week. We should farm the list for candidates.
 +
pagameba : +1
 +
jasonbirch : +1
 +
brayr : Alright, that excludes Traian
 +
Andy_Morsell : +1
 +
pagameba : unless we go to 9 :)
 +
bdechant : +1
 +
brayr : So bring your list to the table next week. Requirements are non-ADSK, significant contribution as a user on the list.
 +
brayr : I vote to wait on 9 until after we are moving
 +
jasonbirch : Sounds good Bob.
 +
TomF : yes, maybe there's other ways to get Traian involved again
 +
jasonbirch : I would like to see it be a developer though.
 +
brayr : Let's consider re-visiting expansion in one month.
 +
Andy_Morsell : Agreed.
 +
danmo : is non-north-american still a plus?
 +
jasonbirch : Yes,
 +
Andy_Morsell : Yes. A bit of a side-track, but I'm curious where everyone is right now? Geographic distribution and all......
 +
brayr : I think so, that would make Haris a prime candidate.
 +
TomF : Calgary
 +
brayr : All Canada + 1 US
 +
danmo : Chicoutimi, Quebec
 +
brayr : Calgary
 +
bdechant : Calgary
 +
pagameba : Ottawa
 +
danmo : (not on the PSC though... sorry for the noise)
 +
jasonbirch : Beautiful downtown Nanaimo, BC, Canada. I thought you were in Ottawa Bob? :)
 +
brayr : np
 +
Andy_Morsell : Fairbanks, Alaska at a client. 10:00 am right now.
 +
brayr : Well I am at the moment, but normally Calgary.
 +
jasonbirch : OK, we need to go after some canadian government funding :)
 +
brayr : Developers are scarce at the moment. Like I said, bring your nominations next week. Jason you could e-mail me yours.
 +
pagameba : or municipal funding!
 +
jasonbirch : mmm, aren't I working hard enough on that?
 +
pagameba : lol ... of course you are
 +
brayr : That's our time for this week. I'll set up an agenda for next week and post a message when the process doc is updated.
 +
jasonbirch : +1 for adjournment
 +
pagameba : +1
 +
Andy_Morsell : +1 see you next week
 +
brayr : +1
 +
brayr : Thanks everyone.

Latest revision as of 10:43, 26 October 2006

MapGuide PSC - Home

Meeting Info

The first meeting of the MapGuide PSC will take place Thursday October 19 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=10&day=19&year=2006&hour=17&min=0&sec=0&p1=0
Location:  The meeting will be held on IRC at #mapguide

For IRC newbies Chatzilla is probably the best way to get going. It works with Firefox and once installed you can log onto the channel by pointing your browser at: irc://irc.freenode.net/#mapguide. You can download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.

Agenda

Minutes

Agreement on

  • Voting primarily by email, following guidelines on PSC page
  • IRC voting allowed with 2/3 quorum (what's 2/3 of 7?) but members unable to attend can veto within 24 hours of posting/emailing of minutes
  • All technical decisions floated to DEV list. Final decisions and other process items made by PSC on PSC list.
  • meetings to be held weekly at this time until boostrapping complete. Will eventually be only held as required with email being preferred .
  • DEV to meet weekly by IRC. Developer members of PSC expected to attend DEV meetings (non-developers welcome). DEV meetings will not start up until we get a bit further into the boot process. Like to the second L in LILO.
  • meeting minutes to be emailed and posted after meetings
  • PSC will be brought up to 7 at next meeting. Expansion considered after a month.


Actions

Bob to:

  • Update PSC document based on feedback
  • Post an initial straw-man roadmap based on current ADSK plans

All to:

  • think about how to fill 7th PSC role. Bring nominations to next meeting for vote. Requirements / desirables: Non-ADSK, not north-american, active on mailing list. Jason would prefer a developer. (guess who's writing the minutes)

Carry Forwards

  • Create template for change requests
  • Evaluate expansion of PSC in one month
  • Vote for 7th initial member


IRC Log

(edited for clarity. original posted to psc at mapguide.osgeo.org mailing list by Paul, though it doesn't appear to have shown up in the archive yet. Let Jason know if you want a copy) 

brayr : Welcome
jasonbirch : Thanks. Is there a logging service for #mapguide? Perhaps qgis could help?
brayr : No not at the moment. That is one of the things we need to sort out. Logging.
brayr : I am an IRC newbie, so help would be appreciated.
brayr : Looks like everyone is here. So let's start with the first item on the agenda.
brayr : I did not get to make another pass at the document this morning (as you probably noticed).
brayr : There was a couple of things in the e-mails I want to work in.
brayr : First is the PSCs responsibility for defining a RoadMap. (thanks Jason) 
brayr : My thinking is that the roadmap would help guide some of the feature decisions. Thoughts?
pagameba : I agree
jasonbirch : Agreed. Obviously, Autodesk has some plans for the product. Can we see those plans and use to help bootsttrap our roadmap?
Andy_Morsell : Would this be more high-level, or very feature specific? Didn't Sean Sternfeldt start something that is still posted on the Wiki?
jasonbirch : That's a wishlist. Diffferent beast.
brayr : yes, we can certainly bootstrap the process with our internal roadmap. But I would really lilke this group to take some ownership and supply input.
brayr : input
jasonbirch : not just input, control. Control Control (sorry, got carried away)
pagameba : How specific do you see the road map being?
brayr : yes that is really what I meant.
pagameba : and will we use the roadmap to seek contributions (funding, code etc)
brayr : Long term roadmaps tend to be theme driven. Short term, e.g next release are more specific.
brayr : Yes
pagameba : ok
jasonbirch : I think there are two categories. Architectural change, and feature implementation. Big features should be in roadmap
brayr : Yes, roadmaps are about big features. Things like Geocoding, or WCS, or ...
jasonbirch : Do changes drive architecture, or do we identify inefficiencies and do architectural change as features when required?
brayr : Could be both.
brayr : I think at this point, architecture is mostly feature driven.
brayr : But there may come a day when that is not true.
brayr : So I'll draft a section on roadmap and then we can iteratate.
jasonbirch : Sounds great.
brayr : Another item in the doc is Process.
jasonbirch : Out of left field... Version numbers. 1.1 is development, 1.2 is release, etc?
brayr : The doc did not clarify if decisions are made and voted on at a meeting like this or the mailing list.
brayr : NO
brayr : I really do not like the even odd thing. Let's table that for a future meeting and we can sort it out.
jasonbirch : OK.
jasonbirch : Do we need quorum? If not, email vote should be fine.
Andy_Morsell : It seems like voting via mail list would be the best as not everyone will always be able to attend each meeting.
brayr : So do we want all decisions made in an IRC meeting or via e-mail, or leave it open for both
brayr : I like e-mail because of timezones, travel, etc.
jasonbirch : And because of lasting record. But that shouldn't prevent us frmo making decisions in IRC
pagameba : it is sometimes more efficient to do it in an IRC meeting ... how about ...
pagameba : if we have a quorum at a meeting (2/3) then we can make a decision 
jasonbirch : Sounds reasonable to me.
brayr : That makes sense. 
Andy_Morsell : Sounds reasonable
pagameba : but there is an opportunity for the non-participants to veto within x days
jasonbirch : 24 hours so we don't get surprised.
brayr : Yea, it needs to be pretty short.
jasonbirch : after putting in lots of work
brayr : Any decision made in IRC needs to be broadcast via e-mail.
brayr : 24 hours from the e-mail seems right.
pagameba : I like it
jasonbirch : I think that the email should be a courtesy, and official from posting of minutes.
jasonbirch : Email is not all that reliable, so members need to take responsibility to check minutes.
brayr : yea that is fine. But I know many people read minutes in spare cycles, but e-mail regularly.
brayr : Its the old push / pull thing
Andy_Morsell : I would like to see minutes emailed and posted
pagameba : I have another process question
jasonbirch : Agreed, but it pervents the "I never got that email" argument. Agreed Andy.
brayr : Yea I like Andy's suggestion.
brayr : Ok, I'll draft that in as well.
brayr : Ask away Paul.
pagameba : MapServer has a TSC as opposed to a PSC ..
pagameba : it makes technical decisions
brayr : They are moving to a PSC. Is that correct Daniel?
pagameba : should we have the concept of a TSC that includes all committers
brayr : I am not sure they intend to keep the TSC.
jasonbirch : That's just elitist bunk (grin) I want to be involved in technical decisions even though I'm not a developer
pagameba : PSC + committers
brayr : The real question here is "does the commiter community get a vote"
pagameba : I'm just thinking that committers may have some valid input/concerns over purely technical issues that currently the PSC would vote on
jasonbirch : I think that we should be able to refer items to the dev@ list for discussion, but retain final decision.
pagameba : yes, exactly !!!
brayr : Well here is a good question. Should the PSC mailing list go away, and all PSC communication happen on dev?
jasonbirch : Or, all technical discussion on the dev list, and process on psc
brayr : Could do
jasonbirch : separate functions. I think anyway.
pagameba : I'm worried that Jason will push for things that are hard to do ;)
jasonbirch : Lol, bad experiences Paul?
pagameba : lol ... no, I swear!
brayr : That is the role of a user in the PSC IMO
brayr : To push
pagameba : I like having separate lists
brayr : Or part of the role anyway. Also to bring balance and end user perspective to decisions
danmo : sorry for the delayed answer... yes the MapServer PSC will *replace* the TSC.
jasonbirch : Let's keep em separated. (hmmm, now I have a song stuck in my head)
brayr : Thanks Daniel!
Andy_Morsell : Separate lists. I have not participated in the dev list to date, but will obviously have to at least start reading the messages.
pagameba : ok ... I would be happy if the process document says that the PSC advertises for comments on the dev list prior to making a decision
jasonbirch : Not much activity yet.
brayr : OK so Process on PSC, development of features, technical stuff on DEV
Andy_Morsell : Jason - a closet Offspring fan? 
jasonbirch : Fraid so.
brayr : Yes I would agree. Any technical item, feature request, etc gets floated on DEV
jasonbirch : Sounds good. Do we have to vote? :)
pagameba : +!
brayr : My concern is that we will see a lot of cross postings.
pagameba : +1
brayr : +! is that a new type of dictorial decision?
pagameba : lol
jasonbirch : it's an override :)
brayr : Yes lets vote on that. DEV for technical, PSC for process. All technical stuff gets floated on DEV.
brayr : +1
jasonbirch : +1
TomF : +1
bdechant : +1
Andy_Morsell : +1
brayr : Done. I'll draft that in as well.
jasonbirch : The dev list has been pretty quiet. Will that change asn this moves to be more of a community project?
brayr : Yes. It is quiet IMO because ADSK does most development. That has to change
danmo : danmo just joined the -dev list and didn't see much activity yet, but I think -dev becoming more alive will be a requirement for graduation from OSGeo incubation
brayr : That makes sense.
pagameba : The various project tracking lists are reasonably busy :)
jasonbirch : Bob, will all Autodesk developers be encouraged/allowed to take a community role, or will they be in a contracted employee role?
brayr : Any objection to me moving the addition and remoaval of members to the process section. Similar to MapServer TSC/PSC doc?
jasonbirch : No objection
pagameba : no
Andy_Morsell : No objection
brayr : They will be encouraged to take a community type of role.
brayr : All ADSK development will be floated via RFC and discussed in dev.
pagameba : like Traian :)
brayr : yea
jasonbirch : lol
brayr : Let me just say it is not easy to break old habits.
brayr : OK, I will move the addition/removal of members to Process.
pagameba : for RFCs is there a format?
jasonbirch : We need to work on one, with suggested elements, etc.
brayr : We need to create one.
brayr : yea
brayr : Let's get this doc settled first. Then move on to that. We should make a list on the Wiki of things to do.
jasonbirch : Let's spend some time on that in the interim and flesh it out at next week's meeting (I won't be here)
brayr : Nice
Andy_Morsell : Is this the regular day and time for the meeting then?
brayr : That is next on the agenda. Meetings.
brayr : Anything else on the document before we move on?
Andy_Morsell : Sorry to jump ahead......
brayr : Np
brayr : Going once.
jasonbirch : I'm happy with the doc. Weekly meetings always going to be required, or weekly to start and then biweekly? If we don't have to make decisions in meetings...
brayr : Ok, I'll update the doc and we'll discuss/approve on the mailing list.
brayr : That is the first question. How often should the PSC meet?
brayr : On IRC that is
Andy_Morsell : Is every two weeks not enough?
brayr : I propose weekly or bi-weeekly until we get things running, then we decide.
jasonbirch : I think that biweekly should be fine, especially since decisions can and generally will be made via email. But weekly for the first month or so.
brayr : +1
Andy_Morsell : +1
jasonbirch : I have to jump through major hoops to get on IRC from work, so can't always be tuned in. Prefer email.
jasonbirch : +1
pagameba : +1
bdechant : +1
brayr : I prefer e-mail as well, so long term I would prefer we mostly operate by e-mail. This is bootstrap time.
brayr : Now for a bigger question. What about DEV meetings.
brayr : Should dev meet weekly by IRC?
pagameba : being a developer, I would say yes :)
brayr : Might force more of an open communication than we are seeing now.
TomF : yeah, I prefer email
jasonbirch : Do you have any problems with corporate firewall Bob?
brayr : No
Andy_Morsell : I agree. But, would it be expected for PSC members to attend each? Or would reviewing the DEV minutes be sufficent? I'm having trouble understanding where the roles overlap.
brayr : e-mail would be fine, but again we are just not using DEV today as much as we should be.
jasonbirch : I don't think that it should be required for PSC to participate in DEV. Just know what's going on enough to vote and guide development of features they have voted on.
brayr : Good question. I think PSC members who are commiters would have to attend the dev meeting.
brayr : Other PSC members optional/
jasonbirch : 2 daytime meetings a week might be a bit of a burden...
Andy_Morsell : OK. But, part of our decisions are based on the DEV discussions and that would only come during the formal change submittal process?
brayr : yes.
jasonbirch : Yes, we will take guidance from DEV of feasibility, but changes will come through process.
brayr : I agree 2 meetings is a lot, but the PSC one will go away I think.
Andy_Morsell : Thanks for the clarification. In case you hadn't noticed, I'm a bit new to this.
brayr : You are not the only one.
jasonbirch : Yes, at some point PSC IRC as required only.
jasonbirch : Yikes, I think we're on schedule...
brayr : yea, so it is really one meeting. The issue I have with IRC is more around timezones. It's hard to get good world-wide involvement via IRC.
brayr : Let's try a couple of dev meetings and see how they go.
jasonbirch : After we get the roadmap?
brayr : Some of this will be an iterative learning process.
jasonbirch : And maybe some techincal feature requests?
jasonbirch : Need to have something to meet ABOUT
brayr : yea, I don't think starting now makes much sense.
brayr : So does this time work for everyone? For the initial PSC meetings anyway?
pagameba : +1
jasonbirch : +1
bdechant : +1
Andy_Morsell : +1
TomF : +1
brayr : Ok, next topic. Initial PSC size.
jasonbirch : The voting structure doesn't require tie breakers.
brayr : We are at 6, need a seventh. Should we go straight to 9?
jasonbirch : Why seven?
brayr : I like odd numbers, just in case we all vote.
brayr : It is not strictly required.
Andy_Morsell : I like 7
jasonbirch : I think we should see where the project goes and keep it small at first. That allows merit-based expansion. Unless you have someone in mind?
danmo : I would tend to agree with jasonbirch on keeping room for adding people once the project gets going
brayr : I have one nomination in mind. I also would like some non North American input/involvement.
jasonbirch : Good idea. Is +1 enough for now, and a commitment to add two more before leaving incubation?
brayr : I don't even know that we need one or two more before leaving. MapBuilder is seven I think.
brayr : But +1 for now seems right to me.
danmo : pagameba: is there minimum PSC size required by incubation? I personally think that 7 should be enough
pagameba : there is not a minimum required
brayr : Any nominations out there?
pagameba : smaller is better for actually achieving concensus
jasonbirch : I guess what I meant, is 1 enough for your desired global inclusion Bob?
brayr : No0
brayr : But it could be.
pagameba : who do you have in mind, Bob?
brayr : I am fine to stay small ongoing. Like no more than 9.
brayr : Traian.
Andy_Morsell : Any more than 9 and it starts getting unmanagable
danmo : Is Traian with ADSK? And how many ADSK people would that make on the PSC?
brayr : His input, involvement, and code contribution are huge. At ADSK he now longer works on the project, nut has stayed involved.
danmo : (not objecting, just wondering at this point)
brayr : nut = but
Andy_Morsell : Well, get him back on the project! ;)
pagameba : +1
brayr : danmo: You hit one of my concerns on the head.
pagameba : :)
pagameba : what about including an FDO person?
jasonbirch : I personally feel that Traian would be a GREAT addition. There would be 4 ADSK on the committee at that point.
brayr : That would make the PSC ADSK, three external.
pagameba : like Haris?
jasonbirch : Or Mateusz
pagameba : Haris has expressed interest in doing some WebStudio stuff
brayr : Haris would be a good addition. I plan to nominate him for the FDO PSC.
pagameba : :)
pagameba : Perhaps because of the close ties, we should plan for 1 member to be on both ...
brayr : There are a couple others on the mailing list as well that are very active users.
Andy_Morsell : Haris would be good. He's obviously extremely smart. Yes, maybe more suitable for the FDO PSC.
jasonbirch : If he's interested in MapGuide it would be great to have non ADSK liason between the two as well
brayr : Yes. Right now I am the only liason.
Andy_Morsell : Good point Jason
jasonbirch : Need to be joined at the mind as well as the hip :)
pagameba : So we have Mateusz, Haris and Traian as possibilities, plus potential from the user's list
danmo : I think that with respect to incubation and for the appearance of independance from ADSK, you should not add more ADSK people at this point... that would definitely help prevent any objections when time comes to graduate from incubation
brayr : We are just about out of time. Let's table this and discuss agian next week. We should farm the list for candidates.
pagameba : +1
jasonbirch : +1
brayr : Alright, that excludes Traian
Andy_Morsell : +1
pagameba : unless we go to 9 :)
bdechant : +1
brayr : So bring your list to the table next week. Requirements are non-ADSK, significant contribution as a user on the list.
brayr : I vote to wait on 9 until after we are moving
jasonbirch : Sounds good Bob.
TomF : yes, maybe there's other ways to get Traian involved again
jasonbirch : I would like to see it be a developer though.
brayr : Let's consider re-visiting expansion in one month. 
Andy_Morsell : Agreed. 
danmo : is non-north-american still a plus?
jasonbirch : Yes,
Andy_Morsell : Yes. A bit of a side-track, but I'm curious where everyone is right now? Geographic distribution and all......
brayr : I think so, that would make Haris a prime candidate.
TomF : Calgary
brayr : All Canada + 1 US
danmo : Chicoutimi, Quebec
brayr : Calgary
bdechant : Calgary
pagameba : Ottawa
danmo : (not on the PSC though... sorry for the noise)
jasonbirch : Beautiful downtown Nanaimo, BC, Canada. I thought you were in Ottawa Bob? :)
brayr : np
Andy_Morsell : Fairbanks, Alaska at a client. 10:00 am right now.
brayr : Well I am at the moment, but normally Calgary.
jasonbirch : OK, we need to go after some canadian government funding :)
brayr : Developers are scarce at the moment. Like I said, bring your nominations next week. Jason you could e-mail me yours.
pagameba : or municipal funding!
jasonbirch : mmm, aren't I working hard enough on that?
pagameba : lol ... of course you are
brayr : That's our time for this week. I'll set up an agenda for next week and post a message when the process doc is updated.
jasonbirch : +1 for adjournment
pagameba : +1
Andy_Morsell : +1 see you next week
brayr : +1
brayr : Thanks everyone.
Retrieved from "http://wiki.osgeo.org/w/index.php?title=MapGuide_PSC_Meeting_10-19-2006&oldid=8904"