Forum .LRN Q&A: dotLRN Governance
I am pleased to announce that Don Baccus has agreed to serve as Chair of thedotLRN Technical Advisory Board. Don is a natural choice given his leadership role with OpenACS and his experience with SloanSpace/dotLRN.
We have asked Ben Adida to serve as dotLRN kernel gatekeeper. Ben will make a decision when he returns in a couple of weeks.
Don will be forming the Technical Advisory Board in consultation with Ben and the community. If you wish to nominate someone or would like to serve on TAB yourself, please contact Don directly.
Don will be forming the Technical Advisory Board in consultation with Ben and the community. If you wish to nominate someone or would like to serve on TAB yourself, please contact Don directly.Al, is Don forming the Technical Advisory Board as president of TAB or project manager of OpenACS? (re: OpenACS members of the TAB will be *asked* to join or will they be *"choosen/nominated/elected"* from the OpenACS community/project?). If this is the latter case, i.e. the community/project "chooses" their representatives, I would like to nominate the same persons (if they are interested) that I have nominated in the dotLRN governance rules thread:
- Ben Adida
- Roberto Mello
- Dan Wickstrom
- Jon Griffin In that list Don was also part of my list of nominations but since he was *asked* to join already, there's no reason to nominate him anymore.
Where should the dotLRN bug tracker reside? More generally, where should the developer community for dotLRN reside? Should it be within the OpenACS web site?OpenACS and dotLRN are separate projects governed by different rules. Hosting the dotLRN developer community at the OpenACS project is making OpenACS look as if it is not neutral, in case other competing projects are founded. So, as far as I'm concerned OpenACS is hosting only OpenACS projects/subprojects.
- It will be easier for newbies if everything techie is in one place.
- It will show that we are a community that works together; it would not go over well with potential adopters of dotLRN if they see that it is based on multiple pieces of code which live in different places. It would look like the communities didn't get along, and that might scare some folks away.
and the most important reason of all...
- The projects all depend on volunteer time, and we need to be sensitive to using that time wisely. Those who are working only on OpenACS can ignore the dotLRN stuff entirely, but those who are working on both need access to both sites, both bug trackers, etc. IMHO it will be a real nuisance if they are in two places.
Right now the number of projects is small, so IMHO there is no real harm in making the dotLRN site a subsite of openacs.org. In the future there may be a proliferation of projects and the volume might become too much; at that point the represtation might change to one page which links out to where the project really resides. But I think it's very important that these projects be presented as part of a larger community and not as satellite efforts, because as long as they are built on top of OpenACS they are not truly independent.
The goal I'm after here is not to promote dotLRN. I'm just as interested, if not more so, in promoting OpenACS. But we have to use the tools we have available and one of those tools is Sloan, which is planning to invest considerable time, effort and money into promoting dotLRN. Every one of those dotLRN sites will also be an OpenACS site, and they'll be high-profile ones in many cases. That can only be good for the acceptance and reputation of OpenACS. So I want to do everything we can, within reason, to help promote *both* OpenACS and dotLRN. And I personally feel that making it's development site a subsite of openacs.org is within reason.
"please contact Don directly."Therefore, I suggest that the selection process goes on in public. [Disclaimer: I'm only participating in this discussion provided that the OpenACS community/project "chooses" its representatives to the .LRN TAB. If that's not the case, I only have to say *one* thing "NO COMMENT".]
"Suspicion and mistrust breeds in the absence of knowledge."
Thank you for your kind words. As I told you after you recently asked me in private: it would be more than an honor.
Let me emphasize that I will serve the growing dotLRN community along with the OpenACS community and I will continue to contribute to both to the best of my ability.
As I told you on the phone I am not interested in controlling anything... I see the EB work as mainly being crisis management, funding, representation, and diplomacy.
I am going to continue to pursue the main goal I had with my team in Heidelberg before you asked me to serve: the internationalization of OpenACS and dotLRN.
After this I will focus on helping create a working consortium, representation from abroad, a bundling of resources to support ideas coming from the TAB/UAB/OpenACS, evangelism, and preventing dotLRN and OpenACS from drifting apart.
I was first giving Al my answer to his question, and second responding with my opinion on your objections. If you wish to raise the same objection over again that's up to you, not me. However, if you prefer that I ignore your comments in the future that's ok with me too.
This needs to be on another thread so I won't post more here except to mention this. Feel free to conact me in private if you wish.
As you know Simon has started a thread on OpenACS governance on the OpenACS boards (although I think Don was wise to move for postponing it until after 4.6 so that all can stay focused... in any case I think everyone needs some time to recover from the dotLRN discussion).
Neophytos, once again I want to emphasize that dotLRN governance has little to do with the OpenACS governance (other than the fact that we would like to see leaders from OpenACS as members of the dotLRN TAB and as dotLRN gatekeepers... see Ben and Don).
As far as the selection of the TAB... as Al mentioned above this is something that Don needs to decide on (another thread might be in order) and I believe it is in good hands. Part of this decision has to take the individuals interests in getting involved with online learning software (an eLearning toolkit if you will) into consideration... this will involve a different focus than that of OpenACS. Please keep this in mind.
Jon: Thank you for your offer, I will contact you with questions. I am aware of work that has already been done... it seems that the internationalization job will mainly consist of consolidating various efforts from the past. I hope to win other peoples help (eventually I hope we can win your help in this area as well Neophytos... among other things internationalized search is also important and your intimate knowledge of OpenFTS is very valuable for all).
Part of this decision has to take the individuals interests in getting involved with online learning software (an eLearning toolkit if you will) into consideration... this will involve a different focus than that of OpenACS. Please keep this in mind.I have no problem if other people participate in the TAB due to their interest with online learning software. But who is called an "*OpenACS* representative" in the .LRN TAB is another story.
Neophytos: There's plenty of work to be done by TAB and by the gatekeepers. If the people whom you have nominated wish to work on dotLRN, I am sure we will find a way to get them involved. Since Don (and hopefully Ben as kernel gatekeeper) need to manage the technical process, we will let them make the decisions.Al, thank you for your message. I hope you realize that I'm not doing all of these in order to promote my nominations. It's mostly a matter of the *way* things are done, rather than who will benefit the most from all of these in the end. I said what I had to say and again, I wish you all the best in your efforts and please try to balance everything in the future. I *hope* we've *all* become wiser from all the things that happened past few days. George Seferis (Literature Nobel Laureate , 1963) wrote once that it is easy to walk on the one extreme or the other -- what's difficult is to walk in the middle, steadily.
I have come to the end. I thank you for your patience. I am also grateful that "the bounty of Sweden" has permitted me in the end to feel as if I were "nobody" - understanding this word in the sense that Ulysses gave it when he replied to the Cyclops, Polyphemus: "outiz" - nobody, in that mysterious current which is Greece.[ The quotation has nothing to do with our discussion but I like it so much I wanted to post it :) ]
-- George Seferis
So maybe we both had this thought independently, which is fine.
It doesn't really matter, what matters are the motivation for doing it, which in my case is a desire to be able to offer hosting to projects that want it, if the community approves. Subsiting means we can let them create their own master template, set up development groups or admin group or whatever their hearts desire all on their own, and can take a domain name like dotlrn.net and point it right at their website.
Now ... your comment asking if other projects with a governance organization different than dotLRN would be treated equally, in my mind, sure - they could ask to be hosted here and if the community approved they would be.
That's my thinking and that's fair, I think.
As far as how the TAB's formed, no, I'm not accepting nominations from the floor and no, there won't be a vote. It's not a political office, it's a technical advisory board, and I'm interested in getting the right mix of people on board, not running a popularity contest.
I know you're going to answer me by telling me what you think that I must do, but you know, Neophytos? Your continuous demands that we follow some process formulated by you is undemocratic to the extreme. You're trying to dictate terms, and that's very annoying.
Where should the dotLRN bug tracker reside? More generally, where should the developer community for dotLRN reside? Should it be within the OpenACS web site?
It's best here to put yourself in the shoes of someone from the future who has not been following all this debating (Imagine I am that person). If I download dotLRN from the dotLRN website (which makes sense so far), when I run into a problem, I will return back to the dotLRN website (common sense move), expecting helpful information about dotLRN to reside there. That means a FAQ, forums, and maybe even a bugtracker.
It would be very unlikely that I, a random person from the future who has not been reading all this debate, would spontaneously decide to check the openacs.org website (and not the dotLRN website) when I run into a problem with dotLRN. The decision of where to put dotLRN related information should be motivated by *What makes Sense to a User*, and that is keeping dotLRN information on the dotLRN website.
IMHO, the best argument for separating the two sites is that the best advice technical users can get will come from OpenACS developers, who all hang out here.
Now, there are arguments on both sides of this, and I certainly am worried about confusing people or, even worse, inhibiting conversations between technical and non-technical users by segregating them. But we can mitigate that by cross-linking the two sites and crafting our message carefully on both. On balance, I think a non-technical users' site hosted by MIT and a technical users' site hosted by OpenACS is probably the best compromise.
Good grief, DonSo you disagree with the premise that the OpenACS community should decide which sites should be hosted here, and which shouldn't?
These are my reasons:
- We only have one account for both.
- It will show the technical relationship between dotLRN and OpenACS, that dotLRN runs on top of OpenACS.
- A good number of users will belong to the same community
- It will show the capabilities of OpenACS as being a REAL COMMUNITY PLATFORM. Subsites, shared forum, etc.
As far as I am concerned I want to put out the political, governance, etc. away from the decision of making dotLRN as a subsite in OpenACS.org. My only concern is convinience and having OpenACS prove that it is a community platform.
I'll post a summary of our adventures in LinuxWorld very soon. It was great and I hope we can make OpenACS a constant present in that event. I'd like to thank Talli/Musea for sponsoring my trip to LinuxWorld (Note: I'm not employed by Musea).
I'd like to volunteer to be on the the TAB for dotlrn, if I may do so myself.
Going back to the really early threads on this topic (pre-dating even the dotLRN bboard), we consistently made a distinction between technical and non-technical "users" (i.e., developers and end users). I think this distinction is wise.
We need to find ways to divorce code from product and technology from marketing. I think it is clear that governance of each of these "sectors" should be divorced from one another.
If I understand the core of Neophytos' concerns they are that somehow technical governance will become subservient to marketing governance. Valid and important concerns.
I feel like the GPL takes care of this. There is no reason that, if dotLRN were to be hosted on openacs.org, ther might not be two developer communities cooperating... a bunch of dotLRN marketing subservient developers contributing code to the core. And a bunch of other independant developers contributing code to the core.
This scenario is MUCH, MUCH, MUCH more likely to be possible if dotLRN code is clearly part of the OACS community by being a project subsite of openacs.org
AFAIK, the TAB would oversee _all_ development so I don't see this as a problem.
And I think it would be great if dotlrn was hosted as a subsite on openacs.org, since it is a project based on it.
Where Is The Technical Documentation?
As far as I know, there is nothing so far in the way of docs:
- no overall dotLRN docs
- no dotLRN package docs
- no engineering docs (requirements/design)
- and no ad_proc doc strings.
OTOH, I -do- understand the situation, that it was necessary to get product into production. However, lack of documentation marginalizes every potential new developer that doesn't happen to be located in the same building where the development is taking place.
If we want to avoid this marginalization of potential new developers, documentation at each level must get into the packages.
Also OTOH, dotLRN is great! I plan on using pieces of it in my jam session community application, when I can finally -learn- about it! (side note, I printed just the dotlrn package alone: seven -hundred- pages! I -really- want docs...)