Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 20:00 GMT on June 10, 2009.
We intend to hold the next meeting on #dspace June 17 at 16:00 GMT. You can see the upcoming (weekly) schedule as well as other DSpace developer events at: http://www.google.com/calendar/embed?src=3mfp5qsv0kejvsbh558lmshujk%40group.calendar.google.com&ctz=America/New_York Anyone is welcome to attend. Meeting Summary: Updates on some of the GSOC projects. A lively debate on the next steps for documentation in 1.6 and beyond. Suggestions of moving to a more online (wiki?) based format; various arguments against. Agreement to accept Jeff Trimble's offer to work on the documentation. A start on clearing up confusion over transitioning DS2 to community control. Transcript: bradmc: Hi folks. We'll start the committer's meeting in a couple of minutes. Thoughts on topics for this week? [4:00pm] stuartlewis: Documentation for 1.6? [4:00pm] bradmc: [4:00pm] kshepherd: hi all [4:01pm] rrodgers joined the chat room. [4:02pm] mdiggory_: G'Day [4:02pm] mdiggory_ is now known as mdiggory. [4:03pm] tdonohue: hello all (as well) [4:03pm] bradmc: Hi folks. So far the proposed topic is Documentation for 1.6. We should also get GSOC updates as agreed in the past. [4:03pm] rrodgers: ditto [4:03pm] bradmc: Anything else for today? [4:03pm] rrodgers: Can I add scm comitter policy? [4:03pm] bradmc: Yep. [4:04pm] kshepherd: i'm just running to the office, won't take long (otherwise i'll be late for work!), back in 10min [4:04pm] • mdiggory can tell his last email was read [4:04pm] bradmc: Shall we start at GSOC updates, then go to doc, and close with scm committer policy? [4:05pm] stuartlewis: Sounds good [4:05pm] rrodgers: OK - I'll start batting [4:06pm] rrodgers: Andrius is still coming up to speed - his prior efforts built off the DAO stuff in the now retired trunk [4:06pm] rrodgers: So he's at a cross-roads - DS2 or 1.5? [4:07pm] rrodgers: I'm not dictating a direction, but if we see a valuable foothold, I think he would take it... [4:07pm] mdiggory: I've been thinking about that too. Maybe best to get the wiki page started and invite comment? [4:09pm] mdiggory: IMO the mappings will be very different, my interest is in the mappings to Fedora Objects [4:09pm] rrodgers: I guess the question is whether we see any benefit in a scoped 1.5ish effort [4:09pm] rrodgers: I mean 1.Xish [4:09pm] mdiggory: I think the 2.0 is the more interesting target [4:10pm] tdonohue: realistically, doesn't DS2 make more sense though? Would it really ever see much usage as a 1.x project? [4:10pm] mdiggory: The lessons I've learn from working on 2.0 is that often the application 1.x doesn't reveal itself until prototyped on 2.0 [4:11pm] mdiggory: I mean "the appropriate application back into 1.x doesn't reveal itself until prototyped on 2.0" [4:11pm] rrodgers: tdonohue, granted but I also think we have to respect the student's desires. Historically, we have used very little GSOC code [4:12pm] mdiggory: also, IMO, we will not allow 2.0 to get stuck the way that the DAO prototype did [4:12pm] rrodgers: in production code bases. [4:12pm] bradmc: mdiggory: That's predicting the behavior of future installations. Dangerous. [4:12pm] mdiggory: rrodgers: I boldly suggest we utilize our new developer policies to change that [4:12pm] tdonohue: rrodgers...understood...i've just always thought it's more *exciting* (for the student and all involved) if there's more of a potential that it would actually be *adopted* into Dspace (isn't that part of the purpose of GSOC anyways) [4:13pm] mdiggory: bradmc: It'll bake your noodle! [4:14pm] rrodgers: OK. I'll suggest he investigate the 2.0 approach. [4:15pm] mhwood: There are rather lower limits to what one generally learns from work that is not used. [4:15pm] mdiggory: Lets ask the questions... What do we want these students to get out of this project? What do "we" want to get out of this project? Is it "just code"? [4:16pm] rrodgers: I don't think so - I think it is a learning /mentoring opportunity [4:16pm] rrodgers: To grow 'future contributors' as it were [4:16pm] bradmc: Should we move to discussing the next project soon? [4:16pm] mhwood: I thought it was an exchange. The community gets code and fresh perspectives; the student learns things you only learn from working on a sizable product, and a bit of reputation. [4:16pm] mdiggory: even moreso... its trying to help the project grow [4:17pm] tdonohue: it's also a way for students to propose/prototype something innovative....(which in some cases could be worked back into DSpace) [4:17pm] • stuartlewis strolls slowly up the crease in the absence of cheif batter Claudia Juergen - this will hopefully be a short-ish update... [4:17pm] stuartlewis: Gaurav has now started looking at implementing a db model to hold the input-forms, and a service to manage it. We've started to ease the pressure up a bit now as mid-term evaluations are at the end of the month. Thanks for all the input you've given so far. [4:17pm] mdiggory: for Google, its fostering greater involvement in OS projects, its creating the next generation of the teams working on such projects. [4:18pm] stuartlewis: W.r.t. mid terms, we've said we need to see good outputs by mid-term, in order to allow a pass. [4:18pm] stuartlewis: That's about it for our update. Any questions? [4:19pm] mdiggory: Three things need to happen before then. (1) the students need to create accounts [4:19pm] kshepherd: back, sorry [4:19pm] mdiggory: (2) we need to get branches in place (in prototypes) [4:19pm] mdiggory: sorry, in (andbox) [4:20pm] mdiggory: (3) We need to see something in place in those locations [4:20pm] rrodgers: Does it need to be code? [4:20pm] mdiggory: I think thats upto the mentor.... [4:20pm] rrodgers: K [4:20pm] bradmc: rrodgers: of course, code now, design later [4:20pm] bradmc: (up to the mentor) [4:21pm] rrodgers: bradmc: of course [4:21pm] mdiggory: Jayan isn't in this channel and he and his student appear to be operating locally. So, I'm not sure how to bring them into this discussion [4:21pm] mdiggory: but from teh last status update, the student was actually producing [4:22pm] bradmc: Okay, we can ping him to see if they can make the next meeting, no sense in discussing in their absence. [4:22pm] mdiggory: certainly [4:22pm] bradmc: Other GSOC thoughts? [4:23pm] mdiggory: This leaves Aaron and Bojan... we will want to ping them as well [4:24pm] bradmc: Okay, I think it's time for midiggory to volunteer to convert docbook into 185 wiki pages, cleanly then ... [4:24pm] mdiggory: [4:24pm] • mdiggory ducks under table [4:25pm] mhwood: That's an interesting question: how *does* one transform wiki markup into other forms (besides HTML) mechanically? [4:25pm] mdiggory: most of the wikis have plugins that do this as I pointed to in my email [4:26pm] bradmc: Actually, that may be the easier part. Getting the initial clean set of wiki pages, all tagged into a topic, and cross linked is the hard piece. [4:26pm] bradmc: You need to look hard at those plugins. Like the Confluence -> pdf is via an ms word template and macros. [4:26pm] mdiggory: bradmc: I know you;ve invested much much time into getting the documentation to docBook... and I think thats a big part of the battle [4:27pm] stuartlewis: The argument that editing docbook is hard, is perhaps wrong, seeing as there are good wysiwyg/docbook hybrid editors? e.g. http://www.oxygenxml.com/docbook_editor.html [4:28pm] bradmc: I think there's a key question underlying this, which is whether we think the documentation needs to live in a structured markup format. [4:28pm] bradmc: Docbook enforces that. Wiki to a lesser extent (when you factor in the post conversion process). Word files to an even lesser extent (since people don't properly use template technology). [4:29pm] mdiggory: sorry, back from phone call [4:29pm] kshepherd: i like docbook [4:29pm] bradmc: Once you accept or reject strict markup, you can then start finding the tools you want. [4:30pm] bradmc: Also, one other thought: I'm not convinced there is sufficient representation of documentation users in this conversation. [4:30pm] bradmc: Lots of tech people though [4:30pm] kshepherd: (or contributors, possibly) [4:30pm] mdiggory: its not so much that its hard, its that is developer centric technology, not user centric technology [4:30pm] kshepherd: wiki makes it very easy to contribute, at least [4:30pm] mdiggory: that is the important goal here [4:30pm] bradmc: What is? Markup? Naw, it comes directly from users (in the publishing industry) [4:32pm] mhwood: I tend toward more structure. I often feel that the trend toward a thousand dabs of Web on the floor leaves us with lots of data, much less information, and very little real knowledge represented. The higher-level organization of the writer's thoughts conveys a lot. [4:32pm] mdiggory: the important goal is that we have a low bar to contributing to and correcting the documentation in a canonical location, wiki gives an immediate loop, docbook + svn does not [4:32pm] bradmc: I'd be thrilled to see somebody show me a roundtrippable doc solution involving a wiki format, that can incorporate our current docs without a huge manual effort, and will enforce a reasonable document structure. I don't think I've seen that yet. [4:32pm] mdiggory: bradmc: its XML... XML is developer centric [4:33pm] bradmc: mdiggory: You've obsessing over how the bits are represented instead of the user interface to the bits. [4:33pm] mhwood: Don't tell them it's XML and they won't notice. [4:33pm] stuartlewis: We already have the wiki with its low bar, but very few people contribute to it. They like to rely on good docs. [4:33pm] bradmc: I also think it's unproven that we'll get any more contributor and user uptake of a wiki format. [4:33pm] stuartlewis: If we are discussion documentation for 1.6, and volunteers are happy to work with docbook, should we stick with this, and reassess the situation for 2.0 (which will naturally be modular which will bring in other issues) [4:34pm] bradmc: +1 [4:34pm] mdiggory: bradmc: I am trying to stay higher up and solve the problem [4:34pm] bradmc: Okay, start writing those 185 wiki pages, then! [4:34pm] bradmc: ha ha, only serious! [4:34pm] mdiggory: if theres an online docBook centric wiki out there, I'll use it in a heartbeat [4:35pm] kshepherd: agreed [4:35pm] mdiggory: stuartlewis: +! [4:36pm] mhwood: If we don't have a problem yet ("volunteers are happy to work with docbook") then we can solve one when we have it. [4:36pm] mdiggory: well, +1 for the case of Jeff, the more hands on board, the more opportunity for solution [4:36pm] stuartlewis: So is everyone happy if we give Jeff svn access to dspace/docs ? [4:36pm] rrodgers: fine with me [4:36pm] kshepherd: yep [4:36pm] mhwood: Yes [4:36pm] bradmc: So this brings us around to the (human) "editor" function. If that's healthy, I suspect the mechanics become easier to handle. Maybe Jeff will be the one. [4:37pm] bradmc: More argument on docs, or should we take up rrodger's scm topic? [4:37pm] mdiggory: Now, this is a role I think we should foster int he community [4:38pm] stuartlewis: As committers, we'll need to help Jeff out though. Anytime we commit something where documentation needs to be changed, and we've not done so, we'll have to update him and tell him what has changed. othweise this will be an impossible task. [4:38pm] bradmc: Yes, we need more editors, or "gardeners" as I've heard the term. [4:38pm] stuartlewis: So do we actively try to recuit some, or see how it goes with Jeff first? [4:39pm] rrodgers: We might also consider not accepting undocumented work.... [4:39pm] mhwood: *applause* [4:39pm] stuartlewis: rrodgers: +1 [4:39pm] kshepherd: +1 [4:40pm] mdiggory: bradmc: I think we should start to list our roles somewhere. (farmers, gardeners, loggers, foresters) [4:40pm] bradmc: I think gardeners apply to wikis as well; it fact, if we had a healthy cadre of wiki gardeners, we'd be in a better position on some of Mark's doc proposals. [4:40pm] bradmc: rrodgers: +1 [4:40pm] mhwood: Or perhaps helping to connect such work with people who can get it documented. There's room for teamwork. [4:40pm] bradmc: mdiggory: +1 [4:40pm] kshepherd: yep [4:41pm] bradmc: Hmm. That sounds like a Jira issue state to me. "Waiting for docs". [4:41pm] mdiggory: well, without guidelines on what constitutes good documentation, thats kinda the pot calling the kettle black [4:41pm] • bradmc is confused [4:41pm] rrodgers: I didn't say good - just trying to establish a cultural norm [4:42pm] stuartlewis: Hadn't thought of using JIRA for longer workflows. Could be pretty powerful. [4:42pm] mhwood: So we need a style manual or something. [4:42pm] mdiggory: sorry, probably too strong an cliche [4:42pm] mdiggory: mhwood: yes, thats more to the point [4:43pm] mdiggory: how to document different parts of the application [4:43pm] mhwood: I think every large, successful project *writes down* its baseline standards of performance. [4:44pm] stuartlewis: Or do we leave that decision to the gardeners, and get them (since they are DSpace power users) to tell us what the guidelines should be? [4:44pm] bradmc: +1 my next point exactly. We need feedback on those guidelines. [4:44pm] mdiggory: true... true [4:44pm] mhwood: We definitely need information on what "good documentation" means, from the people it's for. [4:45pm] bradmc: Okay, shall we add that to the initial inputs to Jeff and see what response we get? Also ask him about multiple "gardeners"? [4:45pm] mdiggory: yes [4:46pm] rrodgers: why not [4:46pm] bradmc: rrodgers: scm committer policy? [4:47pm] rrodgers: OK - I'm just a bit perplexed by the dspace2 policies [4:47pm] stuartlewis: Sounds good - I'll copy all this to Jeff and dspace-commit, and invite him for comment, and welcome his offer of contribution. [4:47pm] mdiggory: howso? [4:47pm] mdiggory: rrodgers: [4:48pm] rrodgers: I mean - that group isn't like a sandbox - it is our official future [4:48pm] rrodgers: As such, we carefully selected existing committers, and added a conspicuous exception for Aaron [4:49pm] rrodgers: since he was doing JISC funded work. [4:49pm] mdiggory: It is a project, and its established its own decisions on membership [4:49pm] bradmc: Ah, but we also explicitly excluded other DS2 contributors who were funded. [4:49pm] rrodgers: So what are they? Did you vote? [4:49pm] bradmc: Thus creating a crisis to be solved. [4:49pm] mdiggory: explicitly excluded other DS2 contributors? who? [4:50pm] bradmc: Ben, for one. [4:50pm] rrodgers: SO are the new proposed members doing funded work? [4:50pm] mdiggory: rrodgers: yes, we discussed and decided in DSpace 2.0 meetings if it would be appropriate to add others to support development [4:51pm] mdiggory: rrodgers: theres not much funding left... but yes. [4:51pm] rrodgers: But no voting procedure, sort of administrative choice? [4:52pm] mdiggory: rrodgers: The challenge is... who is doing he funding and who is doing the work. [4:52pm] bradmc: In this case yes. [4:52pm] mhwood: So when the funding is gone, how does the nature of the project community change? [4:52pm] bradmc: It points out one of several impedance mismatches with the funded work experiment. [4:53pm] rrodgers: I'm worried about the signals is sends - the is not the Apache model we officially embrace [4:53pm] bradmc: I would expect that access to repositories for released code (post funded work) be more in line with the traditional model. [4:53pm] rrodgers: is/it the/it [4:53pm] mdiggory: ok, the current committers on the dspace 2 branch are not exclusive to the rest of the commiters. [4:54pm] rrodgers: mdiggory, explain? [4:54pm] bradmc: But in the pre-release state, it's effectively a separate project that hasn't been donated to the community yet (for better or worse). if the community refuses to allow access to it's SCM facilities, it forces a split. [4:55pm] You left the chat by being disconnected from the server. [4:55pm] You rejoined the room. [4:55pm] bradmc: It's a pragmatic issue, not a policy one. But this is the right time to ask the question about how to move forward. [4:56pm] mdiggory: rrodgers: the current committers on the dspace 2 branch are not exclusive to the rest of the commiters. means that if you want to be in that group and work on it... then just say so [4:57pm] rrodgers: I meant the reverse - can dspace2 committers vote on policy , etc? [4:57pm] mdiggory: you mean policy within the dspace2 project, or across the whole community [4:57pm] mdiggory: ? [4:57pm] bradmc: Ah. No. Unless brought in as full committers. And at some moment, the DS2 needs to move from pre-release to fully managed. [4:58pm] mdiggory: We should be carefull here with that definition of "full commiter" [4:59pm] rrodgers: OK - this clarifies things a bit - and indeed I was thinking about that transition [4:59pm] bradmc: Yes, I'm trying to express the concepts loosely. We need to codify accurately later. Thanks Mark. [5:00pm] bradmc: Obviously, a case where a strong contributor to a project like DS2 wasn't already accepted as a committer would suggest that they be voted in as the project transitioned. [5:00pm] mdiggory: I just want to make sure that we are clear that the community is made up of projects, and those projects have policies (but that there are overarching policies defined by the community) [5:00pm] mhwood: So DS1 and DS2 are distinct projects, each with its own committer group, with some overlap. [5:00pm] mdiggory: mhwood: <-- gets it [5:01pm] bradmc: I'm not sure I'd go that far. [5:01pm] bradmc: The funded aspect confuses things. [5:01pm] bradmc: We need to decide if DS1 and DS2 are distinct, or if its time to treat them as two branches of the same project for administrative purposes. [5:02pm] mdiggory: yes, that is the crux of the biscuit. [5:02pm] bradmc: IOW, the DS1 community needs to accept that merger (or not). DS2 is effectively a donation from a third party organization. [5:02pm] mhwood: To define the relationships among the projects and the community. [5:02pm] mdiggory: bradmc: yes [5:02pm] mhwood: Do we have a DS1 community and a DS2 community? *surprise* [5:03pm] bradmc: We have a DS1 community, and an externally funded project for DS2. [5:03pm] bradmc: Ideally that changes around now. [5:04pm] mhwood: Or do we have a DS community with an established project and an oncoming project in the same product space? [5:04pm] rrodgers: OK, but I would put it as there is a DSpace community - it's not tied to a codebase [5:04pm] bradmc: Yes, that's better. I'm sorry that I have to run, please continue. [5:04pm] mdiggory: I think we need to be careful here. theres a reason we pull DS2 out of the source tree for DS1 and it related to both community and code. [5:05pm] mdiggory: rrodgers: yes. just like thers an Apache community that not tied to code [5:05pm] mdiggory: IMO we pulled DS2 out of the source tree for DS1 to protect the success of both projects [5:06pm] mdiggory: the same reason that dao was demoted to a prototype branch [5:06pm] mdiggory: to assure that the community on each stays healthy [5:06pm] mhwood: There's a need for people working on version N+1 to be relatively free to rethink the way things are done in version N, so long as N+1 still addresses the same need. [5:07pm] mhwood: It's hard to rethink when version N is all around you. [5:07pm] rrodgers: no argument about that - I'm less concerned with the codebases and projects [5:08pm] rrodgers: and more with the DSpace community and how it governs itself. [5:08pm] mhwood: How we remain one community. [5:09pm] mdiggory: rrodgers: as are we all [5:09pm] mhwood: [Good practice here for thinking about the Foundation/Commons merger.] [5:09pm] rrodgers: Yes - and remain true to our stated values (membership by community contribution, etc) [5:10pm] mdiggory: rrodgers: but there are cases where that was too strict and constraining on the growth of the community [5:11pm] mdiggory: there should be a difference between community and project management [5:11pm] mhwood: I think the idea of multiple projects is new to some of us. [5:12pm] mdiggory: certainly for DS1 these values are maintained [5:12pm] rrodgers: brb - sorry [5:12pm] mdiggory: and as DS2 stabilizes and matures and its stakeholders increase, so will the requirement for those values [5:15pm] rrodgers: an interesting transition [5:15pm] mdiggory: or more in the case of "multiplicity", its core subprojects will have those values [5:16pm] mdiggory: well, I think I question the assumed definition of "community value by contribution" [5:16pm] mdiggory: sorry... I meant "membership by community contribution" [5:17pm] rrodgers: that may be, but I think that's what Apache folk mean... [5:17pm] mdiggory: the practice suggested by the Apache Community was based on meritocracy... [5:17pm] rrodgers: yes, measured merit of contribution [5:18pm] mdiggory: But at the project level meritocracy behaves diferently than at the community level [5:19pm] mdiggory: at the project by project level meritocracy is localized, dirty and political [5:19pm] mdiggory: I.E. competition for resources and footprint by different organizations [5:20pm] mdiggory: but at a higher level, it all averages out and looks very democratic [5:21pm] mdiggory: or the assumed definition for "democratic" many seem to ascribe to [5:21pm] rrodgers: Agreed, which is why certain rituals like voting are taken so seriously [5:22pm] mdiggory: rrodgers: I certainly agree and feel that this has been an experiment in growing the community, and that there are lessons to be learned from it [5:23pm] mhwood: Recalling what I think Brad was saying, DS2 is being built by community members but doesn't yet belong to the community. So the rules can be different. Yes? [5:24pm] rrodgers: Good discussion - but having opened this can of worms, I have to run now. Sorry Bye all [5:24pm] mhwood: 'bye. [5:24pm] mdiggory: Thats a perspective. IMO... my analogy is you don't vote on state legislators at teh federal level do you? [5:24pm] rrodgers left the chat room. ("Leaving") [5:25pm] mhwood: Hmmm. Federal rules circumscribe (in certain ways) what state rules can be. Maybe that's the rub here. [5:27pm] mhwood: It sounds like we'll have to revisit this another time? [5:30pm] mdiggory: true. I think this meeting ran off... [5:30pm] mhwood: I need to go too. Good discussion. Thanks! [5:31pm] mdiggory: mhwood: states do have certain liberty to define the rules they will use. but, there is a framework enforced at the federal level. [5:31pm] kshepherd: anything else on the agenda? [5:31pm] mdiggory: No. I'd say that this meeting is adjourned [5:32pm] mhwood left the chat room. [5:32pm] kshepherd: righty-o [5:32pm] • kshepherd sets mode +lurk ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
