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

Reply via email to