[wiki-standards] Comments on Dirk's "simplest process..."

[Filippo A. Salustri]

Hi everyone,

Quick background: I'm a new subscriber to this list.  I've been mucking 
about with wikis for more than 2 yrs now.  I'm writing my own wiki, 
largely for 3 reasons: (a) I don't need a huge infrastructure (like 
tikiwiki or mediawiki offer) and (b) there's things I'd like my wiki to 
do that I can't find in a single alternative, and (c) I have issues with 
many of the wiki shorthand notations I see.  You can see my wiki at 
http://deseng.ryerson.ca/xiki/ - no one can "login" yet; sorry.

As a design methodologist, I have some comments on Dirk's posting of Oct 
30 "Simplest process that could possibly work" 
(http://www.wikisym.org/pipermail/wiki-standards/2005-October/000027.html 
in the archive).

I think it's very important to separate requirements from 
specifications.  Requirements capture the *intention* of what a wiki 
should do; specs cover more of the *how*.  Requirements tell people what 
a wiki is for, what it should let users do.  Specs tell people how a 
wiki will meet the requirements.  Requirements are (should be) driven by 
the user community; specs can be driven by the development team(s).

I also think it would be important to proactively seek out the opinions, 
wishes, and needs of wiki users who are not programmers or involved with 
the administration and upkeep of their wikis.

Dirk wrote:
> I think we already have a 
> good feeling for what's up for specification (markup, interchange, 
> interlinking, ...)

That might be so, but we ought to formalise this a bit with some 
requirements, so that we have a reference to which we can refer as the 
standards progress.

I do agree with Dirk that it's important to have individuals who are 
willing to "champion" particular tasks/specs/whatever.  I've seen few 
successful projects that worked without someone willing to carry the banner.

Dirk also suggested an "approval" process involving showing a spec to 
the list for approval.  This is important too, and valuable because one 
can never tell where a good idea will come from, or who will find that 
obnoxious logic flaw.

I would also suggest that specs should include a "lay person's" summary 
that can be shown to the user community to get their feedback as well.

Putting time limits on reference implementations is very useful, but 
only if there's enough critical mass of personnel and resources in the 
development community.  So I'd suggest having some clause somewhere that 
allows for the timeframe for these limits to vary in response to what 
the development community can do.

I hope this helps, or at least stimulates some other good ideas.

Cheers.
Fil Salustri
-- 
Prof. Filippo A. Salustri, Ph.D., P.Eng.
Department of Mechanical and Industrial Engineering
Ryerson University                         Tel: 416/979-5000 x7749
350 Victoria St.                           Fax: 416/979-5265
Toronto, ON                                email: salustri at ryerson.ca
M5B 2K3  Canada                            http://deseng.ryerson.ca/~fil/