General Pages

Real-Time Chat Using a Web Browser
Real-Time Chat Using an Installed Client
Browse Opticks IRC Logs
Search Opticks IRC Logs
Opticks IRC Bots

Meeting Notes

Page: January 23, 2012 Meeting Notes
Page: January 9, 2012 Meeting Notes
Page: December 12, 2011 Meeting Notes
Page: November 28, 2011 Meeting Notes
Page: November 14, 2011 Meeting Notes
Page: October 31, 2011 Meeting Notes
Page: October 17, 2011 Meeting Notes
Page: October 3, 2011 Meeting Notes
Page: September 19, 2011 Meeting Notes
Page: September 5, 2011 Meeting Notes
Page: August 22, 2011 Meeting Notes
Page: August 8, 2011 Meeting Notes
Page: July 26, 2011 Meeting Notes
Page: July 11, 2011 Meeting Notes
Page: June 27, 2011 Meeting Notes
Page: June 13, 2011 Meeting Notes
Page: May 31, 2011 Meeting Notes
Page: May 16, 2011 Meeting Notes
Page: May 2, 2011 Meeting Notes
Page: April 18, 2011 Meeting Notes
Page: April 4, 2011 Meeting Notes
Page: March 21, 2011 Meeting Notes
Page: March 7, 2011 Meeting Notes
Page: February 21, 2011 Meeting Notes
Page: February 7, 2011 Meeting Notes
Page: January 24, 2011 Meeting Notes
Page: January 10, 2011 Meeting Notes
Page: December 27, 2010 Meeting Notes
Page: November 29, 2010 Meeting Notes
Page: November 15, 2010 Meeting Notes
Page: November 1, 2010 Meeting Notes
Page: October 18, 2010 Meeting Notes
Page: October 4, 2010 Meeting Notes
Page: September 20, 2010 Meeting Notes
Page: August 23, 2010 Meeting Notes
Page: August 9, 2010 Meeting Notes
Page: July 26, 2010 Meeting Notes
Page: July 12, 2010 Meeting Notes
Page: June 28, 2010 Meeting Notes
Page: June 14, 2010 Meeting Notes
Page: May 31, 2010 Meeting Notes
Page: May 17, 2010 Meeting Notes
Page: May 3, 2010 Meeting Notes
Page: April 19, 2010 Meeting Notes
Page: April 5, 2010 Meeting Notes
Page: March 22, 2010 Meeting Notes
Page: March 8, 2010 Meeting Notes
Page: February 22, 2010 Meeting Notes
Page: February 8, 2010 Meeting Notes
Page: December 15, 2008 Meeting Notes
Page: January 25, 2010 Meeting Notes
Page: January 11, 2010 Meeting Notes
Page: December 14, 2009 Meeting Notes
Page: November 30, 2009 Meeting Notes
Page: November 16, 2009 Meeting Notes
Page: November 2, 2009 Meeting Notes
Page: October 19, 2009 Meeting Notes
Page: October 5, 2009 Meeting Notes
Page: September 21, 2009 Meeting Notes
Page: September 8, 2009 Meeting Notes
Page: August 24, 2009 Meeting Notes
Page: August 10, 2009 Meeting Notes
Page: July 27, 2009 Meeting Notes
Page: July 13, 2009 Meeting Notes
Page: June 29, 2009 Meeting Notes
Page: June 15, 2009 Meeting Notes
Page: June 1, 2009 Meeting Notes
Page: May 18, 2009 Meeting Notes
Page: May 4, 2009 Meeting Notes
Page: April 20, 2009 Meeting Notes
Page: April 6, 2009 Meeting Notes
Page: March 23, 2009 Meeting Notes
Page: March 9, 2009 Meeting Notes
Page: February 23, 2009 Meeting Notes
Page: February 9, 2009 Meeting Notes
Page: January 26, 2009 Meeting Notes
Page: January 12, 2009 Meeting Notes
Page: December 29, 2008 Meeting Notes
Page: December 17, 2008 Meeting Notes
Page: November 17, 2008 Meeting Notes
Page: December 1, 2008 Meeting Notes
Page: November 3, 2008
Skip to end of metadata
Go to start of metadata

Special meeting on December 17, 2008

Agenda

  1. Attendance
  2. Announce agenda
  3. Should we require discussion solicitation for all issues which will go into the trunk? (discussion and vote)
  4. What method should be used use to push feature discussions to the email list? (automatic JIRA email, manual emails, digest emails?)
  5. Summary and closing

Notes

Attendance

  • tclarke
  • mconsidi
  • kstreith
  • dsulgrov
  • rforehan
  • gwelch
  • dadkins
  • raevans
  • goffena

Summary

Discussion continued from the previous meeting on the first vote. Multiple points were made until attendees seemed satisfied with the discussion and a vote was held. Based on the results of the first vote, the second vote question was obsolete as it was contingent on approval of the first question.

Decisions

Should we require discussion solicitation for all issues which will go into the trunk? The motion failed. (9 attending, 1 yes, 5 nea, 3 abstain)

Logs

  *** Opened channel log for #opticks at 12/18/2008 2:03:24 PM
14:03 tclarke logging is enabled
14:03 *** mconsidi (n=mconsidi@12.188.157.129) has joined #opticks
14:03 tclarke lets take attendance
14:03 tclarke here
14:03 mconsidi here
14:03 kstreith here
14:03 dsulgrov here
14:03 rforehan here
14:03 gwelch Here
14:03 dadkins here
14:04 raevans here
14:04 tclarke here's the agenda
14:04 tclarke # Attendance
14:04 tclarke # Announce agenda
14:04 tclarke # Should we require discussion solicitation for all issues which will go into the trunk? (discussion and vote)
14:04 tclarke # What method should be used use to push feature discussions to the email list? (automatic JIRA email, manual emails, digest emails?)
14:04 tclarke # Summary and closing
14:04 gwelch On Monday, we may not have heard from all would-be participants
14:05 goffena here if not too late
14:05 tclarke btw, gwelch will be moderating today
14:05 goffena or maybe i'm not to participate
14:05 gwelch of course you should, if you'd like
14:06 gwelch Does anyone want/need a recap of Monday's discussion?
14:06 tclarke as a review, the question we are dealing with
14:06 tclarke is show we require all jira issues have an associated mailing list thread
14:07 tclarke if not, should there be a rule (all new features are required, for example)
14:07 tclarke or should the developer working the issue decide if a thread is needed
14:07 gwelch Thanks, tclarke.
14:07 gwelch Ground rules for today's discussion . . .
14:08 gwelch If you are in the middle of a thought, end your line with ". . ." . . .
14:08 *** tjohnson (i=0cbc9d81@gateway/web/ajax/mibbit.com/x-4d083a73ccd18d2e) has joined #opticks
14:08 gwelch If you're done, end with a "." . . .
14:08 rforehan Seems to me that if a bug fix is transparent to users, there's no need for thread, e.g., fixing crash from attempt to access a null pointer.
14:08 tjohnson Hola! .
14:08 tclarke which suggests that if you have a long thought.....get something written to the chat room so people know you are talking
14:09 gwelch Hopefully we won't walk on each other too much that way . . .
14:09 tclarke ok, who would...
14:09 tclarke like to summarize the argument for all jira issues?
14:10 gwelch Do you want to, tclarke?
14:10 tclarke ok....
14:11 tclarke the main argument for all issues having a thread is that the developer working the issue may not...
14:11 tclarke know all the impact of a change, even if it should not affect the API...
14:11 tclarke i.e. a plug-in might be relying on undocumented behavior, etc.
14:12 tclarke the main arguments against all issues...
14:12 tclarke is a) it takes extra time to wait for discussion...
14:12 tclarke and b) there's a lower signal to noise on the mailing list which could cause readers to skip over potentially important discussion
14:12 tclarke do I generally have those correct?
14:13 tclarke if so, let's discuss
14:13 kstreith i would add a "for" argument...
14:13 kstreith consistency
14:13 kstreith if we only discuss some of the issues on the mailing list, how does a new entrant to the mailing list, know that
14:13 kstreith depending on the volume they may assume we are talking about everything, when in fact we are not.
14:14 tclarke I'll add some information...
14:14 tclarke that may lessen the for argument...
14:14 tclarke JIRA has a capability to generate RSS feeds of issues (searches) which act almost like a "push"...
14:14 tclarke and you can also watch an issue to get emails whenever that issue changes...
14:15 tclarke we could put this information on the web site, possibly even a portlet which shows the past X new issue transistions
14:16 dsulgrov I am not in favor of posting information on all issues to the dev mailing list...
14:16 dsulgrov here's why...
14:16 dsulgrov I agree that information should be posted to the developers mailing list when it affects developers...
14:17 dsulgrov there are JIRA issues, however that do not affect external plug-in developers...
14:17 dsulgrov e.g. OPTICKS-294, involving minor code style changes
14:17 dsulgrov ...
14:18 dsulgrov I think that any information posted to the developer mailing list should be highly relevant to external developers...
14:18 dsulgrov as such, we may be able to establish several guidelines as to when information should be posted...
14:19 dsulgrov two such guidelines would be as follows...
14:19 dsulgrov when we are faced with a design decision that could take one of several paths...
14:19 dsulgrov and we are not necessarily sold on any one path...
14:20 dsulgrov another guideline would be when we are modifying an interface such that plug-in developers would need to rework existing code...
14:21 dsulgrov I think that streamlining this information will help to achieve a balance between posting useful information and not requiring too much extra work for the committers
14:21 dsulgrov finished
14:21 gwelch counter-points?
14:22 tjohnson It sounds like you are advocating discussion for source or functionally breaking changes and not for others...
14:22 tjohnson I can see the merit in this.
14:22 dsulgrov yes
14:22 kstreith ok, let me revisit a few points
14:23 kstreith dsulgrov is brining up the point of relevancy
14:23 goffena like what dsulgrov is thinking.
14:23 kstreith which can potentially be intermingled with tclarke's argument of signal to noise ratio and also tclarke's dicussion of splitting the mailing list into two
14:24 kstreith so, the question is should we not post this information to any mailing list
14:24 kstreith or should we make two mailing lists?
14:24 kstreith hold on..
14:24 kstreith i have another separate point...
14:25 kstreith tclarke made the argument against being that developers have to "wait" for the discussion on the mailing list before they can proceed
14:25 kstreith i think that needs to be discussed, but i do not believe that is strictly required in all cases...
14:25 kstreith ok, done.
14:26 gwelch kstrieth, when would it not be required?
14:26 kstreith ok...
14:26 kstreith if we have a 8 week development cycle, let's say...
14:26 kstreith if you are working on a change in week one...
14:26 kstreith you could post the mailing list about it...
14:27 kstreith but go ahead and proceed and commit that to the trunk without waiting for a resolution on the mailing list...
14:27 kstreith then if someone brought up a valid point in let's say week 6 of development...
14:27 kstreith we could decide to put another bug in and fix that problem in week 6...
14:27 kstreith and then commit that to trunk in week 6...
14:28 kstreith we've still accomplished the goal which is to make the best possible release in a 8 week period...
14:28 kstreith now, obviously a developer has to make a judgement call based upon the code they are working on...
14:28 kstreith and how likely they think it is that someone will point out a change later...
14:29 kstreith that they think they should make...
14:29 kstreith and obviously for large changes, you would want to wait until the discussion is complete on the mailing list...
14:29 kstreith but it is not strictly required to wait.
14:29 kstreith done.
14:29 tclarke it seems to me that not waiting would defeat the main point of this exercise which is to avoid having to redesign/reimplement after the fact based on community feedback
14:29 goffena my thoughts on emailing about each jira issue...
14:30 kstreith the point is to get the best source code in a 8 week period.
14:30 goffena If you must post for each JIRA issue please limit to something similar to one of the following:...
14:30 goffena 1) Send one daily email which contains links to all JIRA issues updated for the day...
14:30 goffena 2) Send one daily email which contains links to all JIRA issues created for the day...
14:30 goffena 3) Send one email each time a JIRA issue is created, with a link to the JIRA issue...
14:30 goffena In either case state in the pushed email notification that developers may log onto IRC and chat about their input/concerns.
14:30 goffena This would makes use of JIRA, IRC and emails in a reasonable fasion, in my opinion.
14:30 goffena done.
14:30 tclarke that's why I suggested rss...
14:31 tclarke as it allows people to generate those sorts of lists...
14:31 tclarke using whichever reader they desire (IE and Firefox have built-in support and there are lots of aggregators like bloglines and google reader)
14:31 dsulgrov kstreith: did you have anything in mind for separate mailing lists?
14:31 kstreith in the previous meeting
14:32 kstreith nevermind what I was about to say...
14:32 kstreith goffena: as an aside, i think you meant something besides when an "issue is created", i think you meant when an "issue is being worked".
14:33 tjohnson What is the point of the discussion on the dev list? People who are really, really interested will watch JIRA issues, participate in IRC meetings, watch RSS feeds, etc. I think the dev list is to throw a wider net and get to people who generally are too busy to do all of that. As such, it needs to be focused so the SNR doesn't get too low.
14:33 * dsulgrov agrees with tjohnson
14:33 goffena 1) for when "issue is being worked"
14:33 goffena 2 and 3) only for when "created"
14:34 goffena ...
14:35 goffena once the developer knows about the issue, they could use JIRA to send them emails about the updated issue (i think that is currently possible). That way only the concerned developers subscribe to the JIRA issue, and only the concerned developer continues to receive emails on updates
14:35 goffena .
14:35 goffena agreeing with tjohnson
14:36 dsulgrov my thought about separate mailing lists is as follows...
14:36 dsulgrov we have a developer mailing list that should contain information relevant to developers...
14:36 dsulgrov we also have a users mailing list that should contain info relevant to users...
14:37 dsulgrov I'm having a difficult time imagining what other list should be made available...
14:37 dsulgrov because less interested parties can check the road map, watch JIRA issues, etc.
14:37 dsulgrov done
14:37 tclarke the other possibility would be a core developer's mailing list...
14:38 tclarke with in depth discussion on stuff plug-in devs don't care about...
14:38 tclarke this is generally done with multiple cc's at this point.
14:38 tclarke .
14:38 dsulgrov who would subscribe?
14:38 tclarke anyone with commit privs
14:38 tclarke .
14:38 kstreith this is used when you have active core contributors that are no singlely located
14:38 tclarke I'm not necessarily advocating such a list, but it would be the obvious addition
14:38 tclarke .
14:39 kstreith since currenly all of core commiters are located in the same area, we haven't had a need for such a list
14:39 dsulgrov kstreith: sure, but IRC seems like a good way to accommodate that
14:39 kstreith yes, i agree and that is what we have been using
14:39 kstreith but one could also use a mailing list
14:39 kstreith done.
14:40 tclarke dsulgrov: I tend to agree at this point and think another list would be superfluous, but it's an option that I thought should be mentioned
14:40 tclarke .
14:40 tclarke it's also possible to have an IRC bot that sends an IRC message when certain JIRA transitions occur
14:40 tclarke .
14:40 tclarke they have one on the various osgeo channels for example
14:40 tclarke .
14:41 kstreith in the interest of time, am i the only one if the camp to send all messages?
14:41 kstreith if someone else in the camp, with me, please speak up
14:41 rforehan I have to leave shortly - I'm in favor of enabling RSS feeds from JIRA so people can monitor issues of interest, but against putting every issue on e-mail.
14:41 kstreith otherwise, I'll be quiet and we can move on
14:41 tclarke we can vote if people think they know where they stand
14:42 dsulgrov do mconsidi, raevans, or dadkins have any thoughts?
14:42 kstreith i'm not asking for a vote at the moment, tclarke
14:42 tclarke the vote would be for or against all issues to the mailing list
14:42 tclarke .
14:42 gwelch other points from anyone?
14:42 kstreith i still have a point i wish to make before a vote, i just want to open the floor to others that might be in the same camp as I
14:42 kstreith .
14:43 rforehan I have to leave now - mark me down as against all issues
14:44 gwelch thanks rforehand
14:44 dadkins Enabling RSS feeds on JIRA would allow interested parties to see activity on all issues, which is functionally equivalent to having all issues on the mailing list, correct?
14:44 kstreith dadkins, not exactly, you can't have discussion inside JIRA
14:44 kstreith it is a one-way communication tool
14:44 kstreith done.
14:45 dadkins but someone could start a thread if desired.
14:45 tclarke perhaps we should think about re-enabling comments in JIRA if we decide we need two way communication on issues
14:45 tclarke .
14:45 tclarke a discussion for another time, but a possibility
14:45 tclarke .
14:45 mconsidi I'm waiting for kstreith to make his last point.
14:46 tclarke as for RSS capability, you can generate a feed from any JIRA search
14:46 tclarke updates to specific tasks currently require a "Watch"
14:46 tclarke .
14:46 kstreith ok, my last point in the discussion for "all" or "some"...
14:47 kstreith i hope we can all agree that none of has any great experience in opening up a large scale development effort (i.e. 4.3.X) to collaboration with anyone in the world...
14:47 *** gmartin_cn is n=gmartin-@nat1.sp.collab.net (Guy Martin)
14:47 *** gmartin_cn is on channels: #opticks
14:47 *** gmartin_cn _is on server irc.freenode.net (http://freenode.net/)_
14:47 *** gmartin_cn has been idle for 1 hour 16 minutes 45 seconds
14:48 kstreith and so I'm afraid that we may be anticipating problems that we haven't yet proven are there...
14:48 kstreith i.e. in code speak, we make think the iter++ should be changed to ++iter to improve performance, but we haven't yet put any timing statements in...
14:48 kstreith so, if you're on the fence, please consider trying the "all" just for this next release...
14:49 kstreith that way we can get actual data points, and then in the future we can decide whether "all" or "some" is the right way...
14:49 kstreith but with actual data points...
14:49 kstreith now, some will say that we can just go the "some" route and get the same data points...
14:50 kstreith i would point out that going the "all" route is the more daring route and the one that requires the least amount of training on the part of new entrants to the community...
14:50 kstreith ok, i'm done.
14:50 tclarke the one counterpoint I make is that we do (sort of) have a data point...
14:51 tclarke it's known that the human brain ignores background noise...
14:51 tclarke and that a data stream with a low signal to noise ratio will be largely ignored due to this (think lots of spam email...that one important one can slip through easily)...
14:52 tclarke the think we are not 100% sure on is if people on the mailing list will consider these extra message as a significant noise source to cause the data stream to be ignored
14:52 tclarke .
14:52 raevans I like having RSS feeds on JIRA, but I don't like requiring to put all issues up on the mailing list...
14:52 raevans since there are some issues that we don't need to have any discussion on.
14:53 kstreith another has summarized parts of my position much better
14:53 kstreith can everyone please read the article at the following link...
14:53 kstreith http://producingoss.com/en/setting-tone.html#avoid-private-discussions
14:54 kstreith thanks, done.
14:54 gwelch any other thought from anyone?
14:54 tclarke one final...
14:55 tclarke I don't think that the link above capture our situation...
14:55 tclarke we are not proposing private discussions...
14:55 tclarke just discussions in JIRA and IRC instead of always on the mailing list
14:55 tclarke .
14:55 dsulgrov also, about the link...
14:55 dsulgrov not all JIRA issues require a discussion...
14:55 kstreith tclarke, depends on whether you view the threshold for getting into JIRA and setting up subscriptions as effectively making things private
14:56 dsulgrov fixing a typo in an error message does not require any discussion
14:56 dsulgrov done
14:56 gwelch We're coming up on an hour, are we ready to vote?
14:56 kstreith just to poke the bear, we can also put all our discussion on webpages we provide no links to
14:56 kstreith it wouldn't strictly speaking be private, from a HTTP standpoint
14:57 kstreith but I think most people might consider it private from a practical standpoint
14:57 tclarke I believe I have made all my points.
14:57 gwelch Is there a desire to include an option in our vote to add an extra “Commit Privileges” mailing list that would house issues not of interest outside the core?
14:57 kstreith to summarize, i believe we have only discussed the "all" or "some"
14:58 kstreith if we vote for "some", there is still further discussion that would need to happen
14:58 kstreith done.
14:58 dsulgrov mconsidi?
14:58 tclarke gwelch: that should be another discussion for another time as there are multiple ways to address that issue which are not really relevant to the current question.
14:58 gwelch understood.
14:58 mconsidi I think that I am willing to get a data point.
14:59 tclarke sounds like we are ready for a vote then? any objections?
14:59 gwelch it seems we may be ready to vote
14:59 tclarke The vote question is: "Should we require discussion solicitation for all issues which will go into the trunk?" Valid answers are +1, -1, or 0/present/abstain ...
14:59 gwelch Vote “1” for posting all JIRA issues on a mailing list . . .
15:00 gwelch Vote “-1” for posting “significant” JIRA issues on a list with RSS enabled
15:00 tclarke only those present may vote (we'll deal with rforehan if necessary later...let's assume abstain for now)
15:00 tclarke .
15:00 tclarke per the agenda, that's the question we are voting on.
15:00 gwelch otherwise, abstain is 0
15:00 tclarke gwelch: we're not voting on two issues right now
15:01 gwelch tclarke, are you for changing the second option to Vote “-1” for posting “significant” JIRA issues on a list
15:01 tclarke there are no options
15:02 tclarke it's a yes/no vote not multiple choise
15:02 gwelch i think we may be saying the same thing, but from a differnt perspective
15:03 tclarke the quoted question I posted is the one in the agenda...that's the question we are voting on
15:03 gwelch let the voting begin.
15:04 tclarke -1
15:04 raevans -1
15:04 kstreith +1
15:04 mconsidi +1
15:04 dsulgrov -1
15:04 gwelch 0
15:04 tjohnson -1
15:04 goffena -1
15:04 tclarke rforehan has left so he is 0
15:05 dadkins 0
15:05 tclarke all votes appear to be in...voting is closed
15:05 gwelch agreed
15:05 * dadkins is a last-minute pollster
15:05 tclarke (2 yea, 5 nea, 3 abstain)
15:06 gwelch the consensus seems to be to not include all issues
15:06 gwelch anything else before we end?
15:08 tclarke there was another question...
15:08 tclarke on the agenda but I believe it was contingent on a yes vote
15:08 tclarke so I move to ignore it as OBE
15:08 tclarke .
15:09 tclarke we'll consider this the summary...there will be a regularly scheduled meeting December 29
15:09 tclarke since it is the week between Christmas and New Years
15:09 tclarke it may be cancelled if not may people are here
15:09 goffena what are vacation schecules
15:09 goffena ?
15:09 tclarke feel free to drop an email to the list if you care one way or another
15:09 tclarke I belive many of the core developers will be available on that day
15:10 goffena ok
15:10 tclarke I'll consider the meeting over
  *** Closed channel log for #opticks at 12/18/2008 3:10:16 PM

Labels

meetings meetings Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.