[09:38:59 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:50:41 EDT(-0400)] * theclown (n=theclown@142.150.154.101) has joined ##uportal
[09:52:11 EDT(-0400)] * anastasiac (n=team@142.150.154.149) has joined ##uportal
[09:54:33 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:46:51 EDT(-0400)] * athena7 (n=athena7@lumina.its.yale.edu) has joined ##uportal
[10:54:13 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-114-2.nwrknj.east.verizon.net) has joined ##uportal
[10:55:24 EDT(-0400)] <jayshao> EricDalquist: around?
[10:56:30 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543729.dsl.bell.ca) has joined ##uportal
[10:56:49 EDT(-0400)] <EricDalquist> hey jayshao
[10:57:22 EDT(-0400)] <jayshao> am looking at the SoC application, and am wondering if we should just submit
[10:57:27 EDT(-0400)] <jayshao> it's fairly straitforward
[10:57:54 EDT(-0400)] <jayshao> and I'm not sure this rises to the level that the steering committee needs to handle, given that it's more a matter of identifiying individual mentors and ideas
[10:58:04 EDT(-0400)] <EricDalquist> yeah ... as much as I would love to be involved I don't think it is a good idea unless we had talked about it with the board/committee
[10:58:17 EDT(-0400)] <EricDalquist> and I really do think at least the steering committee needs to ok something like this
[10:58:26 EDT(-0400)] <EricDalquist> it could end up being a huge distraction if not managed correctly
[10:58:36 EDT(-0400)] <EricDalquist> and sour any future chance of making good use of that time
[10:58:59 EDT(-0400)] <jayshao> I think that depends more on the commitment by the various mentors than anything else
[10:59:11 EDT(-0400)] <EricDalquist> true. but we don't have any of those setup
[10:59:13 EDT(-0400)] <jayshao> especially given that, realistically mentors are unlikely to be coordinating with each other
[10:59:19 EDT(-0400)] <EricDalquist> or any idea of who could do that
[10:59:24 EDT(-0400)] <jayshao> and any viable project would almost have to be relatively standalone
[10:59:27 EDT(-0400)] <jayshao> I was going ask you 
[10:59:35 EDT(-0400)] <EricDalquist> and I won't have time this year
[10:59:36 EDT(-0400)] <jayshao> I think myself and Andrew can both committ as well
[11:03:06 EDT(-0400)] <jayshao> I'm concerned that we may have introduced a level of process that prevents us from taking advantage of emerging opportunities
[11:03:21 EDT(-0400)] <EricDalquist> how is that?
[11:03:23 EDT(-0400)] <jayshao> also that we're starting to move towards defering to committees and working groups that are not as open as the dev lists
[11:03:34 EDT(-0400)] <jayshao> for discussions that should probably be happening "in the clear"
[11:03:35 EDT(-0400)] <EricDalquist> this was suggested with 2 days notice
[11:03:59 EDT(-0400)] <EricDalquist> that is not nearly enough time to really talk about anything in a distributed community
[11:04:38 EDT(-0400)] <EricDalquist> so if you submitted would it be on behalf of CampusEAI?
[11:04:40 EDT(-0400)] <jayshao> is that really so unreasonable given the amount of time our key contributors spend online? Especially given how open most of these applications are, in terms of their being room for negotiation?
[11:04:58 EDT(-0400)] <EricDalquist> yes I think it is
[11:05:00 EDT(-0400)] <jayshao> I would be willing to commit the organization to back any projects we accepted as a mentor
[11:05:10 EDT(-0400)] <jayshao> and to support my time involvement as an administrator
[11:05:21 EDT(-0400)] <jayshao> though ideally I'd like it to be more inclusive on the mentoring side
[11:05:35 EDT(-0400)] <EricDalquist> I would as well
[11:05:45 EDT(-0400)] <EricDalquist> and don't get me wrong I would really like to see us involved in GSOC
[11:06:03 EDT(-0400)] <EricDalquist> but from the JA-SIG point of view there isn't enough time to make any commitment
[11:06:34 EDT(-0400)] <EricDalquist> so I guess my view is that if you do submit the onus would be on you and CampusEAI to interface the GSOC work with the JA-SIG community
[11:07:20 EDT(-0400)] <jayshao> that I'd be willing to do, though if accepted I'd like to support others participation as well
[11:07:29 EDT(-0400)] <jayshao> I'm willing to bear the cost of administration and interface
[11:07:40 EDT(-0400)] <jayshao> but don't want to make it a closed participation process
[11:07:47 EDT(-0400)] <EricDalquist> no
[11:07:51 EDT(-0400)] * apetro_LD830_ubu (n=apetro_L@uni1.unicon.net) has joined ##uportal
[11:07:52 EDT(-0400)] <EricDalquist> and I don't think it would need to be
[11:08:22 EDT(-0400)] <EricDalquist> so back to the time to talk about this point
[11:08:30 EDT(-0400)] <EricDalquist> we've had a whopping 2 posts about this on the dev list
[11:08:34 EDT(-0400)] <EricDalquist> no links to any wiki docs
[11:08:44 EDT(-0400)] <jayshao> apetro_LD830_ubu would you be willing to commit as a mentor for Google SoC?
[11:08:58 EDT(-0400)] <EricDalquist> no real listing of what would be involved or how we would pick tasks to ask students to work on
[11:09:10 EDT(-0400)] <EricDalquist> no idea as to where these people would commit code to
[11:10:35 EDT(-0400)] <apetro_LD830_ubu> jayshao sure sounds like I'm walking into a minefield if I answer that question
[11:10:45 EDT(-0400)] <jayshao> well, we have existing processes for granting committer access, JIRA tracking, and others
[11:10:50 EDT(-0400)] <jayshao> well, some existing processes
[11:11:05 EDT(-0400)] <jayshao> though in reality, is the situation that much clearer for existing committers?
[11:11:10 EDT(-0400)] <jayshao> or say portlet or other projects?
[11:11:34 EDT(-0400)] <jayshao> I think most of the procedural questions apply across the board
[11:11:49 EDT(-0400)] <EricDalquist> yes it is, most of our new committers have experience in the communitity
[11:11:58 EDT(-0400)] <EricDalquist> do we want random students committing to uPorta/trunk?
[11:12:16 EDT(-0400)] <EricDalquist> do we create a branch for each sub-project? If we do that who maintains sync between trunk and the branches?
[11:12:33 EDT(-0400)] <jayshao> I thought I put something into the initial email suggesting branches in sandbox
[11:12:37 EDT(-0400)] <apetro_LD830_ubu> I guess I'd say I'd not thrilled about volunteering to mentor a Google SoC coder at this juncture, given that I haven't cleared it with Unicon and I don't have a recent excellent track record in finding time for this sort of extra effort. But mostly I'm going to keep quiet, since it sounds like I've walked into a heartfelt conversation...
[11:12:50 EDT(-0400)] <athena7> i'd think portlets might be a good candidate for mentored students, potentially, since they're small, contained, and well-defined subprojects
[11:12:56 EDT(-0400)] <EricDalquist> while we don't do any sort of formal code review the mertiocracy approach does add a layer of assurance as to quality of code
[11:13:31 EDT(-0400)] <jayshao> right, my thought was along those lines, or some of the UI type functionality – async channel rendering seems like something that could be a summer project
[11:13:50 EDT(-0400)] <EricDalquist> I like the idea of portlets much more right now
[11:13:57 EDT(-0400)] <apetro_LD830_ubu> async channel rendering is too close to the framework
[11:14:27 EDT(-0400)] <apetro_LD830_ubu> if I do say so myself, that announcements-channel-as-portlet idea has a nice mix of existing well-defined features and opportunity for green-field development
[11:14:41 EDT(-0400)] <EricDalquist> I think the smaller bits of code that portlets represent are much better candidates since they would be easier to mentor and track
[11:14:45 EDT(-0400)] <athena7> yeah, the async channel rendering unfortunately isn't as straightforward as i'd like it to be
[11:14:56 EDT(-0400)] <jayshao> that seems to be a reasonable bound
[11:15:02 EDT(-0400)] <EricDalquist> as Andrew said there is some concern with how much core framework hacking we're going to let developers that we have no experience do
[11:15:03 EDT(-0400)] <athena7> i'd love for someone to try and integrate the stuff from the sunguard branch, but that's too close to the framework too
[11:15:08 EDT(-0400)] <jayshao> also makes things procedurally much simpler
[11:15:12 EDT(-0400)] <EricDalquist> unless someone is going to commit to reviewing all of their code
[11:15:17 EDT(-0400)] <EricDalquist> which is a pretty serious taks
[11:15:35 EDT(-0400)] <jayshao> esp. since we already have many essentially non-supported portlets in Sandbox and the portlets tree
[11:15:40 EDT(-0400)] <EricDalquist> yup
[11:15:48 EDT(-0400)] <athena7> it is, unless they were developing something in tandem with some developers, potentially
[11:15:51 EDT(-0400)] <EricDalquist> so getting some people to help on one of the in-progress portlets would be great
[11:16:00 EDT(-0400)] <athena7> easier to review a project if you're working on it at the same time
[11:16:19 EDT(-0400)] <EricDalquist> but the framework code is not very bite-sizable yet
[11:16:19 EDT(-0400)] <athena7> yeah
[11:16:19 EDT(-0400)] <jayshao> I think that's the intention of the mentoring
[11:16:20 EDT(-0400)] <EricDalquist> some areas are that have been refactored for 3.0
[11:16:29 EDT(-0400)] <jayshao> for it to work I think committing to mentoring a student includes working with them, and taking ownership of the finishd product after
[11:16:40 EDT(-0400)] <jayshao> unit testing maybe?
General
Content
Integrations