Hi all, Looking at the initiative and very constructive comments, I wonder if there is something like:
* Knowledge Base system * - community members can post a KB article and maintain it - linked filespace with the KB article - visitors can add comments/questions - user/system defined fields (categories like mentioned by Charlie) - linked filespace with the KB article > > > devinfo folks, > > It should come as no surprise that someone like myself who > has moved from the development (at least of documentation) > side over into product management side of the house would > wholeheartedly agree with Dan Brown's and Charlie's statement > that we need to get requirements nailed down > before we just rush into implementing a solution. > > Yes, perhaps LinkBase is the way to go... but before we spend > effort on LinkBase - either installing/configuring it and > then populating it on the Mitel end or even just populating > it at Jeff's site - let's be sure it's the right tool. We > already have solutions that don't meet our needs. Let's make > sure that whatever we - collectively - implement does in fact > meet our needs. > > And how can we know what those needs are if we don't spend a > few cycles > figuring that out? > > The existing system hasn't been meeting all of our needs for > quite some time. If we (all of us) implement something > immediately, just because we can do so today, and that system > turns out not to work for us, will we have accomplished > anything? Does it matter if it takes a few days - or even a > week or two (or three) - to determine what we need to do and > then to implement it? > > My suggestion would be that we take Dan Brown's list (below) > and start to flesh out the requirements of what we actually > want to implement. I like Dan's division into 'required' and > 'desirable'. I don't think it will take us that long to > define that list. Between what Dan B. came up with and > the recent discussion on this list, I think we could nail it > down pretty quickly within the next few days. > > [In fact, this would be a *great* place to use a Wiki.... > someone put Dan's list into a Wiki page and then let everyone > know about it... those who care could go in and actually edit > it... and most Wiki tools allow changes to be rolled back if > folks don't agree with them. Anyone have a Wiki site where > they could host such a collaboration? ] > > Once we have that list nailed down, then we all can evaluate > the various solutions (including LinkBase) and determine if > they meet the requirements we have. Maybe LinkBase will > emerge as the way to go... maybe it won't. But if we > collectively *do* decide to use LinkBase it will be because > we all have decided it is the best tool for the job, not > simply because it was something that we could implement immediately. > > My 1.3 cents CAD (2 cents USD), > Dan > > > > > From: Charlie Brady [mailto:[EMAIL PROTECTED]] > > > > > Let's decide what is required/desired, and then see how > LinkBase and > > > some alternatives stack up against the requirements? > > > > I agree; this certainly seems a prudent idea. Toward > that end, here > > are some things that seem necessary/desirable from my perspective: > > > > Necessary: > > > > * Room to store contributed RPMs and documentation. This one, as > > such, is kind of a no-brainer, and we already have it. > > > > * Search function. This would preferably search by name, > > contributor, category(ies), and/or keyword. We don't have > this now, > > and as I see it, this is the biggest shortcoming of the existing > > system. > > > > * Incorporate material that isn't hosted at > > e-smith.org/mitel.com/whatever. For a variety of reasons, > > contributors may prefer to host their own material; for > this project > > to have maximum value, it should deal with that material as > though it > > were hosted locally. > > > > Desirable: > > > > * Self-maintaining. I, as a contributor, would be able to add a > > HOWTO (or RPM) by myself. This would need some safeguards to avoid > > abuse, but I think it would (1) make things more convenient for > > contributors, (2) keep the listings more up-to-date, and > (3) save time > > on Mitel's end. This should allow adding links as well as > uploading > > files. > > > > * Classification. Distinct from (but related to) searching, this > > would categorize items and allow users to filter or browse by > > category. Contributors should be able to assign multiple > categories > > to an item (ideally an arbitrary number of categories). Categories > > would be fairly specific--at least as much so as the ones currently > > used on the contrib HOWTO page. These could refer to what the item > > does (anti-virus, administration, backup, etc.), level of > development > > (alpha, beta, stable), and/or applicable SME versions. It might be > > better to keep these separate--that is, separate entries > for stability > > and applicable versions. Preferably this system would > allow multiple > > items to be indexed together (e.g., a HOWTO and the RPMs it refers > > to). > > > > For contributed RPMs, it seems that rpm2html, or > something like it, > > would be a big help. Unfortunately, it seems that > development's been > > cancelled on it, but it's probably pretty stable already. The RPM > > should already contain a lot of the information people want > > (particularly a description of what the thing is), and a tool like > > this on Mitel's server would save the contributor from having to > > duplicate that effort, or at least give initial values for > some of the > > blanks. The output from rpm2html could then be indexed > like any other > > html document. > > > > The objective of classification points strongly (perhaps > > inescapably) toward a database-driven system. Designing tables to > > allow an arbitrary number of categories for any given item would be > > pretty straightforward, but doing this without a database > would be a > > mess. > > > > - -- > > Dan Brown, KE6MKS, [EMAIL PROTECTED] > > "Since all the world is but a story, it were well for thee > to buy the > > more enduring story rather than the story that is less enduring." > > -- The Judgment of St. Colum Cille > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 7.0.4 > > > > iQA/AwUBPjdO9X6CI7gsQbX8EQI9rgCgjd64G/SseewXbHxGiFpmMVkmikEAoJTW > > I5Ldedq/+4CG3Uw3lQM+BsYN > > =ramd > > -----END PGP SIGNATURE----- > > > > > > > > -- > > Please report bugs to [EMAIL PROTECTED] > > Please mail [EMAIL PROTECTED] (only) to discuss security issues > > Support for registered customers and partners to > [EMAIL PROTECTED] > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > Searchable archive at > > http://www.mail-archive.com/devinfo%40lists.e-smith.org > > > -- > Dan York, Product Line Manager, 6000 Managed Application Server > Mitel Networks Corporation [EMAIL PROTECTED] > Ph: +1-613-592-2122 Cell: +1-613-263-4312 Fax: > +1-613-592-1175 350 Legget Drive, Ottawa, ON, K2K 2W7 Canada > http://www.mitel.com/smallbusiness/ > > -- > Please report bugs to > [EMAIL PROTECTED] > Please mail [EMAIL PROTECTED] (only) to discuss security > issues Support for registered customers and partners to > [EMAIL PROTECTED] To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
