[theforum] Decision time - please cast your vote before noon Saturday Nov 20th (12.00GMT)

[Martin Burns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 18 Nov 2004, at 19:12, Madhu Menon wrote:

> I firmly believe that as a respected community of web developers, a 
> relaunch and move must be an *improvement*, and [not] involve a loss 
> of function. (I refuse to use the word "functionality".)

The fun thing about any general purpose CMS is that it gives you a 
bunch of helpful APIs that make life *extremely* easy building 
functions. It's a tool that you can build sites with, rather than being 
specifically *this* site. So to look back at my 'what sort of site?' 
question - many types of sites could be built. The type of site that we 
have - many contributors, simple workflow, template output - is CMS 101 
these days. And a whole bunch of other things we've struggled with for 
a long time (eg i18n) have also been solved, coded and made freely 
available. So the other fun thing about widely used OSS CMSs is that 
most of the standard stuff *has already been built* and is available as 
modules/plugins/products (pick terminology as appropriate).

For me, the most important thing about a decision to move to drupal 
(and would be the same with Zope or other high level CMS) is that we 
are absolutely *not* at this point deciding whether or not to launch 
the current PoC!

Think of it this way: we're approaching this in layers of increasing 
detail, from basic principles to detailed implementation:
1) Packaged framework -v- bespoke
2) OSS/Not OSS packaged CMS framework
3) Drupal OSS packaged CMS framework -v- A N Other packaged CMS 
framework <-- We are here

At the moment, the key question is "Is the proposed packaged CMS 
framework product *capable* of supporting the kind of site we want?" 
And the answer seems to be: yes. It would be true of a number of other 
options too, but drupal is the one proposed. I certainly don't hold a 
brief for it - I've never run a drupal-based site - so like Adrian, 
I've been doing a fair amount of reading. But as noted above, the 
things we do are not at all unique, special or even particularly hard 
in CMS terms. So even without doing the looking, I'd be *very* suprised 
if *any* half way decent CMS couldn't do them.

At this level, the important thing is to understand the most important 
things that weo needs to do. Not define the detailed "how does it do 
it?" questions (I'll come back to this in a minute, bear with me), but 
look at the top line things. Take a look at elfur's list:
http://evolt.elfur.org/

This is the level of detail (actually a bit more detail than) you'd use 
in a vendor selection exercise. You're asking: "Are they capable of 
doing the stuff?" rather than necessarily "Do they have an off the 
shelf that meets our needs so closely it could have been bespoke so we 
don't have to do any further work?" The Proof of Concept answers many 
of these questions, with a *very* small level of effort.

Now once we have chosen a tool that is capable of fulfilling the key 
requirements, we can start designing exactly *how* each bit works - 
whether the off the shelf modules are good enough as is, or need 
customising. This level of design is part of implementation, which 
usually comes after tool selection. So let's not get hung up on 
detailed requirements at this stage.

I urge you all to look at elfur's list, and if you don't entirely agree 
with it, add yourself to the list of precisely 2 people who have so far 
commented on it. Now think about all those capabilities that drupal 
supports out of the box (or with readily available modules). Now look 
at the others, and look how much the scope of work has been reduced 
from "A full site" to "A few bits, most significantly in one area: 
workflow complexity"

> If anything, we should do stuff that makes the rest of 'em (and that 
> means the rest of the web dev community) sit up and go "wow, now 
> *that* is cool".

Oh for sure. Although I, for one, would be *very* happy with playing 
catch up as a starting point!

Cheers
Martin
(whose current dayjob project - coincidentally - is defining 
requirements for a vendor selection exercise)
- --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBnUZccegecKg1zMsRAlp6AKD3TKFWrCP8ABWjmbRwt/JDewSPZgCg4ebQ
aQCTiBD2MbSXNg5w0CxnvZA=
=MTra
-----END PGP SIGNATURE-----