Greg Smith wrote:
> On Wed, 25 Jul 2007, Dave Page wrote:
>
>> This piece is clearly aimed at end users and shouldn't be on the
>> developers Wiki (which is only for internal project
>> documentation/notes). Please move it over to techdocs, or refocus it
>> as a guide for use by booth staff etc.
>
> I get that this should go somewhere else eventually. If you're telling
> me the Wiki isn't appropriate even as a staging area for building this
> sort of document, which intended to benefit the community as a whole but
> not ready to be "published" more formally to something like techdocs,
> I'll respect that and nuke it from the developer's area. But understand
> that if you push me there immediately, the whole thing will likely just
> die instead. I personally am not in a position to completely flesh this
> out without some help, and I'm not going to put a partially complete
> article somewhere else.
I have no issue with you actively working on it there. There was much
discussion when the wiki was born, the upshot of which was that it will
be restricted to use as a community resource to aid our collective
efforts. It was specifically *not* to become an unofficial documentation
site containing any content intended specifically for end user consumption.
> As a perfect example of this principle, you're telling me that something
> like this might be refocused as a guide for booth staff. I don't know
> what you'd want to meet that requirement--I've never been to your booth.
> But looking at what I've done as sort of a prototype, we could have that
> discussion now in the context of what would need to be changed to
> accomplish that goal. I've found that people in general are really
> quite good at telling you what's wrong with something you've done when
> you give them a target to criticize, and you get much better feedback
> from that sort of process than happens with a more traditional
> brainstorming approach.
The booth guide was just an example of a community resource as opposed
to a user resource. I would have seen it maybe as a document to help
staff helping out at any show or conference around the world ensure
their answers to any questions comparing us to MySQL were fair and accurate.
I should add that I've long wanted to see something along these lines
produced, and I'm happy to see it now. A feature comparison checklist
might also be useful addition (as long as it fairly shows things that
MySQL offers that we don't as well as the other way round).
Regards, Dave