Cool - I think we're all in agreement here. We need a website  
tomorrow. I don't think it needs very much. And we need to flesh out  
some longer term goals of the site (as well as the organization).

But it would be a good demo of proper process if we treated this  
fledgling group as a client and we put it's needs - near and long  
term - down on paper.

We need something out the door soon. But Nate speaks volumes about  
about the problems of managing a slew of open source scripts and  
hoping they work together. Agile today can be very non-agile tomorrow  
if we put a lot of weak mortar in the foundation.

I went to a web standards meetup in 2004 and met Eric and Wayne and  
that group is gone. The new group has plenty of resources and years  
more experience (at least 3 years more!). At Saturday's meeting,  
we'll see what all the needs truly are. The eventual site should be  
emblematic of standards across many disciplines.  This means using  
our resident designers, info designers, front end architects, content  
developers, branding experts, database and application developers and  
understanding the roles they play. Some of this can go on iteratively  
and in parallel so it's not like we're starting a waterfall process.  
"Many hands make light work" but that could end up being "too many  
cooks in the kitchen" if we don't divide the long term projects up  
into smaller bits.

My $2 (corrected for inflation)

Vince


On Sep 19, 2007, at 5:49 PM, Nate Klaiber wrote:

>
> On Sep 19, 2007, at 4:51 PM, Eric Meyer wrote:
>
> Eric,
> This is with all due respect. I have just been involved in way too  
> many projects where people rushed things, only to end us spending  
> way too much time, money, and effort to get what they really NEED.
>
> EM: I'm in agreement.  It seems to me that we should set up some  
> basic stuff-- at least a wiki and a forum, possibly a CMS-- from  
> existing packages so that those communication channels aren't held  
> up by an ongoing effort to create the Perfect Solution.  Later on,  
> if we build our own stuff, we can migrate the content over.
>
> NK: Here is my problem with that. Just throwing a wiki, a forum,  
> and a CMS at it won't solve any problems or help us create a  
> cohesive whole. It will create data islands on the backend, each  
> solution using its own auth/auth and database structure. Our  
> choices to 'migrate the content over' would involve either a)  
> Rewriting the application we are using to fit our needs (never a  
> good idea), or b) creating a migration script that will take the  
> data from the formats that those packages used, and re-formating  
> them to fit our needs (seemingly unnecessary - but our data model  
> might not match their data model).
>
> Neither of these solutions is an easy or quick fix - especially  
> from the open source options. There are many data issues that would  
> need to be resolved.
>
> And this doesn't even touch on the front end issue of giving us a  
> brand/identity. Just as with the data islands, now we have the same  
> sort of islands with the front end: file structure, url structure,  
> css structure and organization, HTML structure and organization -  
> do we really want to manage data islands?
>
> My personal opinion: that doesn't position us very well as a group  
> of web professionals. It doesn't take a web professional to install  
> 3 different open source packages (or paid) and call it a day.  I  
> think going open source with these options will create more work  
> for us than necessary. The communication channels would then become  
> disconnected from the whole. The big picture gets lost.
>
> EM: Yes, we're a brilliant group with a lot of skills.  And we  
> should certainly use that to create great things.  But the same  
> could be said of many W3C Working Groups that have been working on  
> "great things" for years and years and years.
>
> NK: I think that is comparing apples with oranges. We want to  
> create a professional web presence that meets our needs and goals -  
> the W3C Working Groups are working on setting recommendations and  
> standards in place. They have many more variables and constraints  
> they have to work within and around. I know we haven't set out our  
> initial goals, audience, or processes - but I can bet they won't be  
> near as big as what the W3C Working Groups have to work with. Two  
> completely different scopes and resources.
>
> EM: Personally, I tend to be more attuned to the development style  
> that says get something out the door and refine it over time.   
> Flickr is the poster child for this, and it's worked very well for  
> them.
>
> I agree with that 110%. I have the same philosophy of getting  
> things out the door and having the flexibility to grow and expand  
> as necessary. You simply can't wait for 'the Perfect website' - it  
> won't happen. You will worry about all of the little details to the  
> point you never get anything done. I am in full agreement with  
> getting things done. No argument from me there. Also, the scope and  
> resources of Flickr are much larger than ours. Did flickr start out  
> with open source options to get things done, or did they build and  
> then add features as the service evolved (And was bought by Yahoo)?
>
> My personal opinion: for the sake of 'getting things out the door'  
> - you can't sacrifice your goals, quality, and your time. Heck,  
> it's why my personal site is still stuck on Wordpress. I thought it  
> would initially be a great solution to get me up and running and  
> out the door, and now I have to spend the time to actually build to  
> my needs (versus digging through the wordpress tag soup and  
> architecture). Time that would have been better spent building it  
> right in the first place. When you use open source, you are subject  
> to their coding standards (both front end and back end), their  
> database schema, and their URL/Routing/Dispatch­ing. Throw several  
> packages into the mix and the maintenance now escalates...
>
> EM: As for "why the rush?", I've seen this group bloom and die  
> before. The more momentum we give it, the better chance it will  
> avoid death. Getting our own site with our own communication  
> channels will boost that momentum quite a bit.  I don't want to  
> wait for that boost. Besides, with software in place, we'll have  
> something to react to, in terms of "we should have that feature in  
> our thingy!" and "I hate that feature, let's never do that in our  
> thingy!" and why can't we do such-and-so? let's make sure our  
> thingy does that!".
>
> I understand the need for momentum. I am trying to think in terms  
> of simplicity. I am sure we all have ideas of 'features' that our  
> site should have. This is why we, as a collective group, need to  
> sit down and really hash out our 'needed' features and build from  
> there. Features are going to be subjective, just as the design will  
> be. We need to avoid feature bloat and give us the tools we need to  
> communicate effectively, both internally and externally. Keeping it  
> simple.
>
> Again, I fail to see how software packages will help us to react to  
> that. A CMS, forum, and wiki each have distinct structure, schemas  
> and functionality - much of which I am sure we will want to connect  
> to each other.
>
> Example: A simple aspect of logging in as a registered user. One  
> system uses SHA1 encryption with a salt. One system uses MD5  
> without a salt. One system doesn't encrypt at all. One system uses  
> ACL with MPTT, another uses a roles table. One system handles  
> authentication via sessions stored on file, one system handles  
> authentication via sessions stored in a database. Are we just going  
> to maintain three different databases that require us to login in  
> the wiki, the forum, and the CMS?
>
> EM: Anyway, my point being that I'd rather we ship early and often,  
> even though it means some extra effort, than do tons of work on the  
> ultimate solution and risk never shipping.
>
> NK: I would rather see us build with a solid foundation, and then  
> ship early and often - versus throwing random pieces of software  
> into the mix. That extra software will require much more than some  
> extra effort, much more. Let's sit down as a collective group and  
> really see what features are needed, what is our message going to  
> be, who will our message be aimed towards, and give us a solid base  
> to work with.
>
> We can sit down and dream together. Both long term and short term.  
> Then we take all of those pieces and organize them into a workable  
> timeline to allow us to ship early and often. I can guarantee in  
> the long run it will be much less hassle than several open source  
> software packages. Everyone can be involved. Those who are here to  
> learn can now engage in the process of building something and  
> understand how something was made, not installing something.
>
>
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to  
> everyone on this mailing list ([address removed])
> This message was sent by Nate Klaiber ([address removed]) from  
> Cleveland Web Standards Association.
> To learn more about Nate Klaiber, visit his/her member profile:  
> https://webdesign....­
> To unsubscribe or to update your mailing list settings, click here:  
> https://www.meetup...­
>
> Meetup.com Customer Service: [address removed]
> 632 Broadway New York NY 10012 USA
>