September 24th km4dev TAG Skype call
From KM4Dev Wiki
km4dev Technical Advisory Group Meeting Notes - September 24th, 2008
Present: Mark Hammersley, Lucie Lamoureux, Karel Novotny, Michael Roberts, Matthew Slater, Nancy White
Regrets: Pete Cranston, Atanu Garai, Giora Hader, Shikha Shrestha,
Ref: - September Message about Skype call to the km4dev TAG group
Ref: - September Message about Skype call Agenda km4dev TAG group
Contents
The problem
- Our community needs technical tools to support its activities and our current toolset has a) lack of integration across three main tools and b) one of the three is broken
- Lucie reiterated that the current platform Xaraya is broken and that we don't have a big budget (10K CAD for creation/hosting)
- What do we rely upon in Xaraya, what do we no longer use? What activities must the CMS support?
- Cost is an issue.
- There is no additional money to maintain the site at this time
- Talking right now about preparing a new proposal in terms of funding. Have some funds though 6/2009 but then unknown. - (In other words, we'd have to raise the funds)
- Access is an issue
- Conversation supported via an email list is core activity and functionality
- desire for more Web 2.0 options but recognize bandwidth does not allow for all. So need options for both new experimentation and support for low bandwidth
Timeline
- Lucie would like to wrap up this consultation in September and have some recommendations/options to present to the km4dev CORE Group
- Would like to implement a new km4dev webspace by the end of 2008, if possible but will probably go into early 2009
- Is this realistic???
Community Activities that Need Supporting
- Activity: ongoing community conversations - primary
- General sense to use an email solution, perhaps Dgroups as core. Recognize DGroups is strong for supporting email based conversation, but not a full tool for other activities. DGroups Plus something else (Drupal, Ning, etc.)Need to consider if these other tools are useful supports for the conversational activity, or if they are under the generic "CMS"/Community knowledge base and networking activities
- Activity: support community knowledge base (currently on Wiki and broken CMS)
- easily editable by community
- document sharing capability
- Wiki and or/CMS such as Drupal
- Activity: support of community relationships/networking
- Profiles, finding people
- currently profiles barely used on Xaraya, no social netorking capabilities, hard to even find a member of the community much less know where they are, what they do
- Consider Ning
- Activity: support experimentation with new technologies in application in development context
- experiment with tools in ad hoc manner and potentially recommend one or more for adoption by community
- Activity: KM4Dev Journal - currently on a publication platform and do not know if Exec Editors are interested in or willing to move to another platform (UPDATE: Journal might be moved to another platform as of May 2009. Journal Eds in talks with Routledge but still unconfirmed).
- Must follow up with them to find out what they need
- we wish to keep a close association with the journal
- Journal - opportunity to have something well designed for supporting that journal
- Atanu has ideas and is interested to assist in this project
- Regarding journal: we could ask if other dgroups users have similar requirement
- Journal platform. this is a bit trickier. The journal is a bit of a side project w/r/t KM4Dev. The three co-editors (Sarah, Julie and Lucie) use an open source platform from UBC to create/publish the journal. It is an online epublishing platofmr. To transfer would need to be to another epublishing tool and some resistence from editors to do move platforms.
- General description of our needs
- Not too complicated - we need a balance between innovation/experiment and bandwidth issue
- Our processes and values have to stay in the mix, regardless of what tools we pick. The more complicated we get, the more we have to attend to issues of inclusion and process.
- Need something as integrated AND low cost AND low maintenance as possible
Action Items
- KM4dev CORE team: To Propose that some one(s) be DGroups Beta testers so we can quickly get a sense of what features DGroups will have and how they might support our community activities
- Mark Hammersley : To mention to Dgroups partnership to find a new Dgroups sponsor of km4dev so new groups can be created
- The organisations currently represented on DGroups' board are:
- Euforic (Peter Ballantyne)
- ICCO (Maarten Boers)
- IICD (Christian Kreutz)
- Hivos (Paul Maassen / Hapee de Groot)
- CTA (Kevin Painting)
As previously mentioned, Helvetas is a Partner and Riff Fullan is their representative. I would suggest that you discuss first with him, before possibly making a joint representation to Peter and/or Maarten.
- Mark Hammersley : To Map desired activities to DGroups and then identify gaps
Platforms discussed
Dgroups
- We have history with and loyalty to DGroups. KM4Dev is a visible community within international dev world, keeping our support of Dgroups is an important gesture.
- If we can continue, it would be seen positively by a lot of people
- DGroups option is a pretty good one. If DGroups exec want to keep KM4Dev, willing to accomodate this group (costs to a minium for KM4Dev - what does that mean) and DGroups is expandable
- We haven't seen it yet but hearing - it may be a good core to integrate into.
- Email is and will stay as key tool. If DGroups remains strong, well functioning tool, then we should try to stick with it
- Dgroups is an out of the box solution, there is an assumption it would be inexpensive to migrate to this platform, but may require some administrative time
- Will there any additional functionality that we need to consider as look at solutions ( integration, features we won't need to get elsewhere but can find in DGroups, etc. )
- Open modular architecture" with APIs in and out
- Dgroups development impacts km4dev choices
- Intergtation is a concern if we stay with dgroups
- To use DGroups, you must be sponsored by one of those sponsors ( who would sponsors km4dev )
- What implications are there for existing groups compared to those that will be created. Right now you ask an org for them to create a DGroup for you.
- No CMS in the new Dgroups? Still primarily a discussion based tool with a few things that could be mashed up?
Briefing - Dgroups 2.0
- Brief for the new DGroups platform is that it should initially be as similar as possible to the present DGroups system - retaining simplicity but with the ability to "mash" with other online services (e.g. wikis, content management, blog). Email remains at the core.
- Also looking at how to get tags in. Right now it is a word on the wishlist.
- Biz model - no proposals to change current model
- Likely to be a change in the support arrangements. Historically could only receive tech support via partner orgs. New company hosting will provide support to all groups, providing tech groups are vouched for by one of the 27 orgs
- Intention is to keep it simple, probably resistance to CMS, but probably a wiki component
- Since there exists a modular architecture, we can add other components with shared member authentication.
- The understanding is that groups will be able to control what they plug into Dgroups
- Example: there has been discussion that dgroups will offer a wiki plug-in but that individual groups could select other wikis if they wished
- DGroups 2.0 will have personal profiles and a file repository
Ning
- Karel has been experimenting with Ning
- Has content backup
- Possible problem with access for low bandwidth users
- Ning email integration is not very strong
- Is there the possibility to link with Dgroups similar to Facebook?
- Make sure it connects well with an email solution
- Is modular. gives output, can program applications to plug in.
- NING might be too flashy for low bandwidth, but need to look at other free/cheap hosted service that has a development community around it.
- Need to check if there is full email functionality in Ning? What I know is that it just sends alerts, not full content and you have to go to site to post. Is that correct?
Drupal
- Matthew pitched Drupal as a very modular and easy to install/maintain platform for km4dev
- Matthew interested to bid on a Drupal solution for km4dev
- Concern whether there is enough money for this solution and so something ready made might be better for km4dev
- Drupal doesn't have to be expensive. It's all about the amount of customization
- Templatable, no bandwidth issues
- Make sure it connects well with an email solution
- There are bridges between Drupal and mailing lists.
- More accurately, drupal is a content management framework - it can plug into many things
- Drupal doesn't have a mailing lists but w/ organic groups module can have email functionality
- There is also a plugin for a full mailing list manager such as mailman, ezmlm, and an even better one that connects it to Sympa using organic groups
Other portals
- Joomla, Plone, Liferay mentioned but not discussed
Key Features
- Email part is central
- Need something as integrated AND low cost AND low maintenance as possible
- Keep it modest
- If it isn't good on the bandwidth side, then take it off. We are trying to reach out to more southern based partners
- We are still at core an email centric community. Some would love to add RSS as an option along side. But still core is email conversation and not yet to the level of sophistication to use work arounds to access email.
- Regard RSS as a critical tool for processing large amounts of information, but may not yet be core for km4dev in the way email currently is
Open Source
- Raised many times by community members - need to keep it on the radar but it is not the only issue
- More important if such solutions will mean a difference between us maintaining something and someone else maintaining. Might be important at this moment in time to not have to host our own.
Systems Integration
- Risky to start integrating system for a small project only
- Concern about mashing together too many solutions and concerned about maintenance cost out of things put together out of good will. Contract with vendor or something to keep it going.
- Need to be careful not to get carried away with features (Feature creep)
- Want it to be as integrated as possible. Agree there is an issue w/ the management in terms of funding. But reality of this CoP. We have some funds now, to transfer/create/move about the tools.
- Raising the issue of authentication/single sign on across tools (perhaps openID - to be integrated into Drupal, Dgroups, possibly Ning) - multiple accounts will create barrier
- Are we looking at something that is mashup between Dgroups and another platform like Ning or Drupal?
- Attend to how overlap in platforms happens.
- DGroups is working hard to keep up with all the requirements of its users but it does provide more or less the right subset of functionality. (????)
- Drupal will do everything that's required, and is much more flexible but each Drupal instance is customised, so it will need some individual maintenance.
- So it's a question of buying into a process over which we have some control, or, assembling a custom solution (OR IS IT BUILDING BACK UP SLOWLY?)
Other comments
- Are we still a loose community or do we have organizational backing 2-3 years in the sense responsibility of the service has to be also there - some technology and support
- Less reliant on worrying on funding, the more we can focus on community
- Find a way to support the continuum of needs in our diverse community
