Re: [pgsql-www] Developer's Wiki

I have now moved the wiki installation to:

http://developer.postgresql.org/

Where it is currently available for use by any hackers for non-end-user
related activities. I haven't changed Greg's original configuration at all
so it is still open for use by anyone at present, however I have added an
introduction to the front page warning that end-user related content may be
removed without notice. I've also added a couple of sections under which to
add links to projects and management documentation hosted on the wiki.

Let's see how it goes for now, and if it gets abused in anyway we can review
whether or not we need to think about moderation.

Regards, Dave.

On Sat, Sep 02, 2006 at 08:33:41PM +0100, Dave Page wrote:
> I have now moved the wiki installation to:
>
> http://developer.postgresql.org/

Ok, it looks like pages can be arranged hierarchically.

It would seems like pages named:

Todo:<todo topic>

would be a good idea for detailed info on todo items (and progress
info). With

Todo:Contents

being a front page?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout said:
> Ok, it looks like pages can be arranged hierarchically.

Well, a prefix like "Todo:" is not the incantation one needs to use to
arrange pages in hierarchies. You probably want "/" to indicate a subpage:
i.e. "Parent/Child". See
http://meta.wikimedia.org/wiki/Help:Link#Subpage_feature

> It would seems like pages named:
>
> Todo:<todo topic>
>
> would be a good idea for detailed info on todo items (and progress
> info).

I suggest you just give pages names that describe the content of the page,
and then have a category for all the pages that constitute TODO items.
See:

http://meta.wikimedia.org/wiki/Help:Category

-Neil

On Sun, Sep 03, 2006 at 08:30:13PM -0700, Neil Conway wrote:
> Martijn van Oosterhout said:
> > Ok, it looks like pages can be arranged hierarchically.
>
> Well, a prefix like "Todo:" is not the incantation one needs to use to
> arrange pages in hierarchies. You probably want "/" to indicate a subpage:
> i.e. "Parent/Child". See
> http://meta.wikimedia.org/wiki/Help:Link#Subpage_feature

It also says it's not enabled by default. Is it enabled?

I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be "developers only - to the
exclusion of users" or "developers only - but accessable to anyone".

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martjin,

> I was actually hoping for more feedback on the content itself. I'm
> still not clear if it's supposed to be "developers only - to the
> exclusion of users" or "developers only - but accessable to anyone".

It should be readable by everyone, but editable only by authorized users.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus <josh(at)agliodbs(dot)com> writes:

>> I was actually hoping for more feedback on the content itself. I'm
>> still not clear if it's supposed to be "developers only - to the
>> exclusion of users" or "developers only - but accessable to anyone".
>
> It should be readable by everyone, but editable only by authorized users.

I think the lessons of wikipedia is precisely that you *don't* want to add
such barriers. You want to let people add stuff pretty much freely. That
encourages people to get involved and put up information.

Experience shows that most people are cooperative most of the time. If there
turns out to be particularly contentious areas you can restrict access to
those areas to authorized users or ban ip addresses.

I've already put some stuff up there. I didn't plan to, but when I was
browsing I had ideas and the ability to add content was just one click away...

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Greg,

> I think the lessons of wikipedia is precisely that you *don't* want to add
> such barriers. You want to let people add stuff pretty much freely. That
> encourages people to get involved and put up information.

The other lesson of Wikipedia is that maintaining wiki quality for a generally
editable wiki requires a full-time dedicated staff. We don't even have any
volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
you're volunteering.

This is *particularly* true of the TODO stuff. We simply don't want Joe User
adding their personal wishlist to the TODOs, and that's exactly what will
happen if the TODO list is world-writable. TODOs should be items which have
been hashed out here on the Hackers list, and the wiki page should list the
specification which is the general consensus.

If we had a "user documentation wiki", then *that* should be world-editable,
but again that would require community volunteers to dedicate to cleaning it
up. The developer wiki is by and for actual contributors.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Gregory Stark wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>>> I was actually hoping for more feedback on the content itself. I'm
>>> still not clear if it's supposed to be "developers only - to the
>>> exclusion of users" or "developers only - but accessable to anyone".
>> It should be readable by everyone, but editable only by authorized users.
>
> I think the lessons of wikipedia is precisely that you *don't* want to add
> such barriers. You want to let people add stuff pretty much freely. That
> encourages people to get involved and put up information.

I don't agree, you should also look at the recent post and fork by one
of wikipedia's co-founders. The developers wiki should only be edited by
authorized users.

Now, getting authorized should be easy as reasonably possible, but
having a wholesale editing orgy on the wiki responsible for tracking
postgresql developer information is not a good idea.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Joshua D. Drake wrote:
> Gregory Stark wrote:
>> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>
>>>> I was actually hoping for more feedback on the content itself. I'm
>>>> still not clear if it's supposed to be "developers only - to the
>>>> exclusion of users" or "developers only - but accessable to anyone".
>>> It should be readable by everyone, but editable only by authorized
>>> users.
>>
>> I think the lessons of wikipedia is precisely that you *don't* want to
>> add
>> such barriers. You want to let people add stuff pretty much freely. That
>> encourages people to get involved and put up information.
>
> I don't agree, you should also look at the recent post and fork by one
> of wikipedia's co-founders. The developers wiki should only be edited by
> authorized users.
>
> Now, getting authorized should be easy as reasonably possible, but
> having a wholesale editing orgy on the wiki responsible for tracking
> postgresql developer information is not a good idea.

I agree.
Banning IPs is simply not feasible.
I think a minor moderation step during the signup is little overhead and
ensures we know who changed what etc. This is obviously not only
important for blaming but also great for talking to people about a given
page when it comes time to update it.

I think however there should be a "section" that is free for all. It
should be clearly labeled with parts are free for all and which are not.
It should be easy to move pages from one section to the other and back.

Essentially I would say the wiki should be open to anyone who signs up,
however there should be pages that are only writeable to people inside a
special group. I am not sure how the ACL works in the current wiki. SOme
wikis allow you to define ACL's by page, some allow you to create
subwikis with different ACLs etc.

regards,
Lukas

Josh Berkus <josh(at)agliodbs(dot)com> writes:

> The other lesson of Wikipedia is that maintaining wiki quality for a generally
> editable wiki requires a full-time dedicated staff. We don't even have any
> volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
> you're volunteering.

Bullshit. Most pages on wikipedia don't require any attention from such staff.
There are *millions* of pages constantly being updated something that only
works because of that dynamic. Only a small number of pages need any special
attention.

The wiki has been sitting there for two weeks and hasn't had any problems.
It's already getting more attention and updates than the techdocs wiki which
still has articles up from 2001 that are no longer relevant and in some cases
are actively misleading.

Putting barriers up blocking people trying to help isn't any guarantee of
quality. What it does guarantee is irrelevance.

> This is *particularly* true of the TODO stuff. We simply don't want Joe User
> adding their personal wishlist to the TODOs, and that's exactly what will
> happen if the TODO list is world-writable. TODOs should be items which have
> been hashed out here on the Hackers list, and the wiki page should list the
> specification which is the general consensus.

Frankly that's what we have today and that's why it's useless. Things only get
put on the list when everyone who cares already knows what has to be done and
then nobody looks at it because there's nothing there they don't already know
about.

A TODO list people can freely add stuff to is precisely what would make it
useful. It would have things we don't already know.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>> The other lesson of Wikipedia is that maintaining wiki quality for a generally
>> editable wiki requires a full-time dedicated staff. We don't even have any
>> volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
>> you're volunteering.
>
> Bullshit. Most pages on wikipedia don't require any attention from such staff.

This does not help your argument.

> The wiki has been sitting there for two weeks and hasn't had any problems.
> It's already getting more attention and updates than the techdocs wiki which
> still has articles up from 2001 that are no longer relevant and in some cases
> are actively misleading.

Techdocs is a different problem all together. Josh has already mentioned
some problems with it. I can mention more.

1. It isn't easy to login
2. It is even harder to create a login
3. There is no creation of login for most people because they don't know
they have to go to the community portion of the www site to get to it.

I am sure their are other problems on the inside, I haven't actually
ever logged in ;)

>
> Putting barriers up blocking people trying to help isn't any guarantee of
> quality. What it does guarantee is irrelevance.

Again you argue without actual evidence. Wikipedia is a success it is
however it does have quite a bit of problems as well. A simple but very
straightforward signup mechanism isn't going to stop most people.

>
> Frankly that's what we have today and that's why it's useless. Things only get
> put on the list when everyone who cares already knows what has to be done and
> then nobody looks at it because there's nothing there they don't already know
> about.

Anytime I have asked for something to be put on the TODO list, it is. As
long as I can provide a practical reason as to what it is and why it
would be good.

That part of the TODO works just fine.

Now, do I think there is improvement to be made? Of course but the
current TODO is far from useless.

>
> A TODO list people can freely add stuff to is precisely what would make it
> useful. It would have things we don't already know.
>

I am just going to hope that you are kidding about this one.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Gregory Stark wrote:
>> A TODO list people can freely add stuff to is precisely what would make it
>> useful. It would have things we don't already know.

> I am just going to hope that you are kidding about this one.

Fortunately, none of the real developers would have to pay any attention
to any such page ... and you can bet they wouldn't.

regards, tom lane

On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > Gregory Stark wrote:
> >> A TODO list people can freely add stuff to is precisely what would make it
> >> useful. It would have things we don't already know.
>
> > I am just going to hope that you are kidding about this one.
>
> Fortunately, none of the real developers would have to pay any attention
> to any such page ... and you can bet they wouldn't.

Well, there is a reason why I put a big label there "Unofficial TODO
List". I tried to make it clear that it's not an official stance of the
project.

If someone wants to spend an afternoon putting up a coherent
description of their wishlist item complete with possible problems and
solutions, then I don't see why we should stop them. The page someone
has put up covering XML told me more about the current state of XML
support in postgres than a few hours of archive searching would.

It's just not official, that doesn't make it any less useful.

Two points I'm not clear about on this thread though:

1. Authorized user: is that someone with an account, or someone who has
been authorized by someone else?

2. I can see the official todo list being in CVS, which gives it all
the access protection it needs. A wiki todo list can stay where it is,
just that it's not official.

[I've just made a reference to the TODO list in CVS from the wiki, that
should help].

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

> The wiki has been sitting there for two weeks and hasn't had
> any problems.

Uh, you mean apart from the fact that it took very little time (days,
IIRC) before we had people writing attempts at user documentation,
somthing that we already have *two* different systems (interactive docs
+ new techdocs) for, and specifically said we absolutely did not want on
this wiki? IIRC, that got on there long before *any* content related to
what was actually supposed to be there..

> It's already getting more attention and updates than the
> techdocs wiki which still has articles up from 2001 that are
> no longer relevant and in some cases are actively misleading.

It's in the process of being cleaned up, mainly by Robert Treat. I'm
sure he'd appreciate help.

Why would *this* wiki be less suceptible to the same kind of issues than
the old one? That's more an argument that we *will* have this problem on
the wiki.

//Magnus

> Techdocs is a different problem all together. Josh has
> already mentioned some problems with it. I can mention more.

[warning: thread hi-jack]

> 1. It isn't easy to login

Really? You're kidding, right? You click a link that requires login, and
you get a browser login box. How much easier can it be?

> 2. It is even harder to create a login

Again, really? If yo uget the login prompt and hit cancel (or just login
with an invalid password), that says "you need a community login. If you
don't hav eone, click here to read about it." If you "click here", you
get to the page where you sign up.

Now, explaining this process on the frontpage of the techdocs part of
the site might not be a bad idea at all (in fact, it's a good idea :-P),
but do you honestly think the process is complex? If so, what should we
do to make it easier?

> 3. There is no creation of login for most people because they
> don't know they have to go to the community portion of the
> www site to get to it.

See above, you don't need to do this.

> I am sure their are other problems on the inside, I haven't
> actually ever logged in ;)

You should, we'd like to know about them so we can fix them.

//Magnus

> Two points I'm not clear about on this thread though:
>
> 1. Authorized user: is that someone with an account, or
> someone who has been authorized by someone else?

IIRC, the idea was "someone with an account". Basically you add a (very
very small) hurdle so you only get the people who actually *care* to
write things. But if you do care, it's not a lot of work. You also get
traceability, so you can talk to whomever wrote a certain thing.

I don't see any gain in having someone specifically authorize who can
write to it.

//Magnus

On Sun, Sep 17, 2006 at 03:09:29PM +0200, Magnus Hagander wrote:
> > The wiki has been sitting there for two weeks and hasn't had
> > any problems.
>
> Uh, you mean apart from the fact that it took very little time (days,
> IIRC) before we had people writing attempts at user documentation,

<snip>

Really? Where was that? Did it get deleted in the meantime? Who's
responsible for that kind of thing?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

> > > The wiki has been sitting there for two weeks and hasn't had any
> > > problems.
> >
> > Uh, you mean apart from the fact that it took very little
> time (days,
> > IIRC) before we had people writing attempts at user documentation,
>
> <snip>
>
> Really? Where was that? Did it get deleted in the meantime?
> Who's responsible for that kind of thing?

Yes.
Dave took it off when he moved the wiki to it's correct place (being
developer.postgresql.org)

AFAIK, nobody has stepped up to actually take *responsibility* for
maintaining the wiki - both software and content-wise. But I may have
missed something while I speed-read some lists after getting back.

//Magnus

> 1. Authorized user: is that someone with an account, or someone who has
> been authorized by someone else?

In my mind it is someone who without threw a process of email
confirmation. Just to help stave off the amount of trolling that may happen.

Joshua D. Drake

>
> 2. I can see the official todo list being in CVS, which gives it all
> the access protection it needs. A wiki todo list can stay where it is,
> just that it's not official.
>
> [I've just made a reference to the TODO list in CVS from the wiki, that
> should help].
>
> Have a nice day,

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

>
>> 1. It isn't easy to login
>
> Really? You're kidding, right? You click a link that requires login, and
> you get a browser login box. How much easier can it be?

What URL are you talking about?

http://www.postgresql.org/docs/techdocs

Where do I click login? Where do I click create account? Where do I
click to login?
>
>> 2. It is even harder to create a login
>
> Again, really? If yo uget the login prompt and hit cancel (or just login
> with an invalid password), that says "you need a community login. If you
> don't hav eone, click here to read about it." If you "click here", you
> get to the page where you sign up.

You are corrent, now that I have tried it.

If I click edit, and then cancel because I don't have a login I get a
page that tells me:

* Login required

* Accessing this resource requires a community login. If you don't have
* one, you can read about it here. To try again, just press your
* browsers Refresh button.

Which pretty much goes against how every other site in the world does
it. I shouldn't have to throw an exception to perform the correct behavior.

That page that tells me where to login should come *BEFORE* I get a
login prompt.

>
> Now, explaining this process on the frontpage of the techdocs part of
> the site might not be a bad idea at all (in fact, it's a good idea :-P),
> but do you honestly think the process is complex? If so, what should we
> do to make it easier?

Let me rephrase. It is not complex, it is not standard. Which makes it
confusing.

What I expect is this:

Open web browser
Go to techdocs

Either the first thing I see is,

* You are not logged in, if you wish to edit content click here to
login or create an account.

* When I click edit the above happens.

>> 3. There is no creation of login for most people because they
>> don't know they have to go to the community portion of the
>> www site to get to it.
>
> See above, you don't need to do this.
>

You are correct but most people are going to be confused. They are going
to click edit, see a login/password they don't have and move on. Heck I
probably have hit cancel before and didn't even read the text after.

Why?

Because the text after a login failure or cancel when using httpd auth
is almost ALWAYS telling me I need a correct login. Not giving a link to
login.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Magnus Hagander wrote:
>> Two points I'm not clear about on this thread though:
>>
>> 1. Authorized user: is that someone with an account, or
>> someone who has been authorized by someone else?
>
> IIRC, the idea was "someone with an account". Basically you add a (very
> very small) hurdle so you only get the people who actually *care* to
> write things. But if you do care, it's not a lot of work. You also get
> traceability, so you can talk to whomever wrote a certain thing.
>
> I don't see any gain in having someone specifically authorize who can
> write to it.

Yeah I would agree. My idea was just that people would actually create
an account and be email confirmed.

Joshua D. Drake

>
> //Magnus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:

>> 1. Authorized user: is that someone with an account, or someone who has
>> been authorized by someone else?
>
> In my mind it is someone who without threw a process of email confirmation.
> Just to help stave off the amount of trolling that may happen.

I guess it depends on whether you feel the larger of the project's problems is
too many people trying to help who must be stopped before they do something
that may need to be corrected or too few people getting past the natural
barriers to being able to contribute.

The former would be a great problem to have but I don't see any evidence of
it.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

> >> 1. It isn't easy to login
> >
> > Really? You're kidding, right? You click a link that
> requires login,
> > and you get a browser login box. How much easier can it be?
>
> What URL are you talking about?
>
> http://www.postgresql.org/docs/techdocs

Yes.

> Where do I click login? Where do I click create account?
> Where do I click to login?

You click to do whatever you want to do - say edit a page or create a
new page. When you do, you will be asked to log in. There is no point in
asking you to log in when you don't need it (such as for reading pages)

> You are corrent, now that I have tried it.
>
> If I click edit, and then cancel because I don't have a login
> I get a page that tells me:
>
> * Login required
>
> * Accessing this resource requires a community login. If you
> don't have
> * one, you can read about it here. To try again, just press your
> * browsers Refresh button.
>
> Which pretty much goes against how every other site in the
> world does it. I shouldn't have to throw an exception to
> perform the correct behavior.

No, that's correct. But in *normal* access, you just get the login
prompt and you go for it. The usability issue is definitly with the
signup though - do you think it'd be enough to just add a blurb about it
on the first page of techdocs?

> That page that tells me where to login should come *BEFORE* I
> get a login prompt.

Here, we clearly disagree, I think. If you mean a system like pgFoundry,
where you find where you want to go and edit something (say a tracker),
then you have to specifically go log in (because you never remember to
do that when you get there in the first place - or you may have received
the link in email), at which point you are promptly sent off to a
completely different page than the one you wanted to edit...

> Let me rephrase. It is not complex, it is not standard. Which
> makes it confusing.
>
> What I expect is this:
>
> Open web browser
> Go to techdocs
>
> Either the first thing I see is,
>
> * You are not logged in, if you wish to edit content click
> here to login or create an account.
>
> * When I click edit the above happens.
Depends on whose standard you look at, I guess. This is how most
"proper" sites work, IMHO. There are a whole lot of sucky sites out
there, though :-P

Therere is anothe rproblem with that one - it does not scale. It
requires every pgae to be dynamic and look if you are logged in.

> Why?
>
> Because the text after a login failure or cancel when using
> httpd auth is almost ALWAYS telling me I need a correct
> login. Not giving a link to login.

Yes, this is definitly a problem.

again, you think it'd be enough to stick it o nthe frontpage of
techdocs, or do we need a small blurb on every page next to the edit
links?

//Magnus

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

> AFAIK, nobody has stepped up to actually take *responsibility* for
> maintaining the wiki - both software and content-wise. But I may have
> missed something while I speed-read some lists after getting back.

I'm responsible for the software. I'll certainly help out with the
content when I can as well, but it seems we are still tying to hash
out some ground rules at the moment.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200609171112
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFFDWXnvJuQZxSWSsgRAiy2AJ0eBq4uvb4V74WY/Ym8CZjxzGfnGACeN67+
ww7Qj91OCyk39MoidcqhDnA=
=MiZH
-----END PGP SIGNATURE-----

Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
>>> 1. Authorized user: is that someone with an account, or someone who has
>>> been authorized by someone else?
>> In my mind it is someone who without threw a process of email confirmation.
>> Just to help stave off the amount of trolling that may happen.
>
> I guess it depends on whether you feel the larger of the project's problems is
> too many people trying to help who must be stopped before they do something
> that may need to be corrected or too few people getting past the natural
> barriers to being able to contribute.

That is a good point. I see it as more of a problem with crap content
that could occur and thus good content won't.

Joshua D. Drake

>
> The former would be a great problem to have but I don't see any evidence of
> it.
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Sat, 16 Sep 2006, Josh Berkus wrote:
Hi,

> Greg,
>
>> I think the lessons of wikipedia is precisely that you *don't* want to add
>> such barriers. You want to let people add stuff pretty much freely. That
>> encourages people to get involved and put up information.
>
> The other lesson of Wikipedia is that maintaining wiki quality for a generally
> editable wiki requires a full-time dedicated staff. We don't even have any
> volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
> you're volunteering.
Then it will need not be a wiki, just make a website.

>
> This is *particularly* true of the TODO stuff. We simply don't want Joe User
> adding their personal wishlist to the TODOs, and that's exactly what will
> happen if the TODO list is world-writable. TODOs should be items which have
> been hashed out here on the Hackers list, and the wiki page should list the
> specification which is the general consensus.
>
> If we had a "user documentation wiki", then *that* should be world-editable,
> but again that would require community volunteers to dedicate to cleaning it
> up. The developer wiki is by and for actual contributors.
>
>

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
>> Fortunately, none of the real developers would have to pay any attention
>> to any such page ... and you can bet they wouldn't.

> If someone wants to spend an afternoon putting up a coherent
> description of their wishlist item complete with possible problems and
> solutions, then I don't see why we should stop them.

Because if they're willing to put any actual effort into it, the right
way is to post that same item to the mailing list where it can be
discussed. If it survives such discussion (very possibly in a modified
form) *then* it belongs on a TODO list. The first problem with a wiki
TODO is that it will not reflect any sort of community consensus, only
the opinions of whoever edited the page last. The second problem is
that setting it up represents a unilateral attempt to redefine (bypass?)
the community's design/development process, which is a process that has
served us well for many years and is not showing any signs of being
broken.

regards, tom lane

Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>
>> On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
>>
>>> Fortunately, none of the real developers would have to pay any attention
>>> to any such page ... and you can bet they wouldn't.
>>>
>
>
>> If someone wants to spend an afternoon putting up a coherent
>> description of their wishlist item complete with possible problems and
>> solutions, then I don't see why we should stop them.
>>
>
> Because if they're willing to put any actual effort into it, the right
> way is to post that same item to the mailing list where it can be
> discussed. If it survives such discussion (very possibly in a modified
> form) *then* it belongs on a TODO list. The first problem with a wiki
> TODO is that it will not reflect any sort of community consensus, only
> the opinions of whoever edited the page last. The second problem is
> that setting it up represents a unilateral attempt to redefine (bypass?)
> the community's design/development process, which is a process that has
> served us well for many years and is not showing any signs of being
> broken.
>
>
>

I agree with lots of this.

Being slightly more abstract, we are grappling with a couple of
different kinds of objects here: discussions and decisions. The mailing
list is a very good way of having a discussion, and a wiki is IMNSHO a
poor substitute. Ditto, bulletin board, web forum, blog ..... The
reason is simply that with a mailing list all you need is a subscription
to get the info delivered to you in a medium everybody uses. It's push,
not pull, and that's very appealing. Any other mechanism requires the
user to seek the location of the discussion actively to some degree.
Conversely, the very unstructured nature of the mailing list(s) makes
them a poor medium for capturing decisions. That's why some of us have
advocated use of a tracker to capture decisions about development
directions, because the TODO list doesn't seem appropriate. But an open
wiki would be a horrible substitute for the TODO list - it would turn it
from a list that reflects at least some discussion and consensus into a
mere wish list of no authority whatsoever. IOW, it is the exact opposite
of the direction I believe we should be headed.

I use wikis in my work as a good way of capturing all sorts of
information I want to keep. But I have generally found them to be less
than successful as a way of capturing discussions or developing coherent
bodies of technical information and decisions. Comparisons have been
made with WikiPedia - they are inappropriate. Quite apart from anything
else Wikipedia survives through the work of a huge team of editors who
review the work of contributors. And they still run into trouble. We
don't have the resources and we don't need the fights. So let's not go
there.

The only good purpose I can see for a developer wiki is as a place to
publish information that is too large for the mailing lists. Currently
we provide web and other space for a few users - a wiki would allow us
to provide publishing facilities in a central spot for a significantly
wider group of people, with very little cost.

Tom proposed a modest roadmap type experiment a week or so ago. I'd like
to see that pursued. After all, we know of some things that are at least
at first cut stage for 8.3, and a few things high on may people's
agenda. I'd also like to see some work done on using a tracker (for
features as well as bugs). The rest of what's been talked about strikes
me as wasted effort, to be honest. We seem to be running in a few
directions which look like dead ends to me. Let's pick one or two
strategically, and follow those instead.

cheers

andrew

> Tom proposed a modest roadmap type experiment a week or so ago. I'd like
> to see that pursued. After all, we know of some things that are at least
> at first cut stage for 8.3, and a few things high on may people's
> agenda. I'd also like to see some work done on using a tracker (for
> features as well as bugs). The rest of what's been talked about strikes
> me as wasted effort, to be honest. We seem to be running in a few
> directions which look like dead ends to me. Let's pick one or two
> strategically, and follow those instead.

There are a couple of people helping me with pgbugs.commandprompt.com.
We could always use a couple more.

Joshua D. Drake

>
> cheers
>
> andrew
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
>
> >Tom proposed a modest roadmap type experiment a week or so ago. I'd like
> >to see that pursued. After all, we know of some things that are at least
> >at first cut stage for 8.3, and a few things high on may people's
> >agenda. I'd also like to see some work done on using a tracker (for
> >features as well as bugs). The rest of what's been talked about strikes
> >me as wasted effort, to be honest. We seem to be running in a few
> >directions which look like dead ends to me. Let's pick one or two
> >strategically, and follow those instead.
>
> There are a couple of people helping me with pgbugs.commandprompt.com.
> We could always use a couple more.

Sorry if I missed an email, but help doing what? Are we actively trying
to do something with that besides just play around with it (I'm already
pretty well-aware of bugzilla's capabilities...)
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
>>> Tom proposed a modest roadmap type experiment a week or so ago. I'd like
>>> to see that pursued. After all, we know of some things that are at least
>>> at first cut stage for 8.3, and a few things high on may people's
>>> agenda. I'd also like to see some work done on using a tracker (for
>>> features as well as bugs). The rest of what's been talked about strikes
>>> me as wasted effort, to be honest. We seem to be running in a few
>>> directions which look like dead ends to me. Let's pick one or two
>>> strategically, and follow those instead.
>> There are a couple of people helping me with pgbugs.commandprompt.com.
>> We could always use a couple more.
>
> Sorry if I missed an email, but help doing what? Are we actively trying
> to do something with that besides just play around with it (I'm already
> pretty well-aware of bugzilla's capabilities...)

Well yes, we are trying to use it :). If it becomes useful enough, we
hope that the project as a whole will move to it. If it isn't useful
enough, then we can say "We have actually tried it for the project, it
didn't work."

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Ok, so what is it you need help with?

On Sep 18, 2006, at 1:24 AM, Joshua D. Drake wrote:

> Jim C. Nasby wrote:
>> On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
>>>> Tom proposed a modest roadmap type experiment a week or so ago.
>>>> I'd like to see that pursued. After all, we know of some things
>>>> that are at least at first cut stage for 8.3, and a few things
>>>> high on may people's agenda. I'd also like to see some work done
>>>> on using a tracker (for features as well as bugs). The rest of
>>>> what's been talked about strikes me as wasted effort, to be
>>>> honest. We seem to be running in a few directions which look
>>>> like dead ends to me. Let's pick one or two strategically, and
>>>> follow those instead.
>>> There are a couple of people helping me with
>>> pgbugs.commandprompt.com. We could always use a couple more.
>> Sorry if I missed an email, but help doing what? Are we actively
>> trying
>> to do something with that besides just play around with it (I'm
>> already
>> pretty well-aware of bugzilla's capabilities...)
>
> Well yes, we are trying to use it :). If it becomes useful enough,
> we hope that the project as a whole will move to it. If it isn't
> useful enough, then we can say "We have actually tried it for the
> project, it didn't work."
>
> Joshua D. Drake
>
>
> --
>
> === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> Providing the most comprehensive PostgreSQL solutions since 1997
> http://www.commandprompt.com/
>
>

--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim Nasby wrote:
> Ok, so what is it you need help with?

see previous discussion about what is required to keep a tracker system
healthy. In particular:

. items appearing in other media need to be put in the tracker
. items entered in the tracker need to be regularly triaged, reviewed
and updated.

Systems lacking this amount of TLC rapidly become useless, and in fact
unused.

Also, if we are in fact going to use bz, there is probably some dev work
that should be done to improve/extend its email functionality, to make
it fit the way we do business better.

cheers

andrew

>
> On Sep 18, 2006, at 1:24 AM, Joshua D. Drake wrote:
>
>> Jim C. Nasby wrote:
>>> On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
>>>>> Tom proposed a modest roadmap type experiment a week or so ago.
>>>>> I'd like to see that pursued. After all, we know of some things
>>>>> that are at least at first cut stage for 8.3, and a few things
>>>>> high on may people's agenda. I'd also like to see some work done
>>>>> on using a tracker (for features as well as bugs). The rest of
>>>>> what's been talked about strikes me as wasted effort, to be
>>>>> honest. We seem to be running in a few directions which look like
>>>>> dead ends to me. Let's pick one or two strategically, and follow
>>>>> those instead.
>>>> There are a couple of people helping me with
>>>> pgbugs.commandprompt.com. We could always use a couple more.
>>> Sorry if I missed an email, but help doing what? Are we actively trying
>>> to do something with that besides just play around with it (I'm already
>>> pretty well-aware of bugzilla's capabilities...)
>>
>> Well yes, we are trying to use it :). If it becomes useful enough, we
>> hope that the project as a whole will move to it. If it isn't useful
>> enough, then we can say "We have actually tried it for the project,
>> it didn't work."
>
>

Andrew Dunstan wrote:

> Being slightly more abstract, we are grappling with a couple of
> different kinds of objects here: discussions and decisions. The mailing
> list is a very good way of having a discussion, and a wiki is IMNSHO a
> poor substitute. Ditto, bulletin board, web forum, blog ..... The
> reason is simply that with a mailing list all you need is a subscription
> to get the info delivered to you in a medium everybody uses. It's push,
> not pull, and that's very appealing. Any other mechanism requires the
> user to seek the location of the discussion actively to some degree.
> Conversely, the very unstructured nature of the mailing list(s) makes
> them a poor medium for capturing decisions. That's why some of us have
> advocated use of a tracker to capture decisions about development
> directions, because the TODO list doesn't seem appropriate. But an open
> wiki would be a horrible substitute for the TODO list - it would turn it
> from a list that reflects at least some discussion and consensus into a
> mere wish list of no authority whatsoever. IOW, it is the exact opposite
> of the direction I believe we should be headed.

I agree pretty much. However I disagree that a wiki is not useful to
summarize discussion from the mailinglist. All that it needs is people
that are humble and do not push their own agendas. If necessary they
should discuss their summaries with members of both/all sides of a given
discussion and with members of the core group.

regards,
Lukas

Andrew Dunstan wrote:

> Well, of course, the internet is renowned for its preponderance of
> people overburdened with humility and fairness. :-)

I think if you ask the php development team the chances are high that
they will agree that I have done exactly that for the PHP todo list.

> Seriously, what will be the point? It strikes me as likely to be a huge
> amount of wasted effort. If the wiki is updated by others then they will
> be using the wrong forum (should be on the mailing list). And I suspect
> nobody much will use it to look for anything.

The point is that you no longer argue in circles, do not have to use the
ever intimitating "read the archives" (which buys newcomers nothing
since archives are essentially useless if you are trying to understand
the contents of a lengthy discussion you did not partcipate in yourself)
and give people some transparency.

> As for the TODO list, its items belong in a tracker, IMNSHO, as feature
> items (as opposed to bugs). So exactly what would go on a wiki? ISTM we
> are in danger of wanting to use technology because we like it, rather
> than because it is appropriate.

The problem with a tracker is that again like complicated mailinglist
threads, they rarely summarize things. Since most trackers are not
threaded, they are less confusing to read up afterwards, but at the same
time due to lack of threading they are less useful at discussing the issue.

So imho a tracker is nice to make it very easy to query the status of a
giving issue (fixed in branch xyz etc), a mailing list is great for
discussions and a wiki is great for summarizing discussions. The wiki
can be linked to inside the tracker/mailinglist.

regards,
Lukas

PS: Did you intentionally only reply to me?

On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote:
> I agree pretty much. However I disagree that a wiki is not useful to
> summarize discussion from the mailinglist. All that it needs is people
> that are humble and do not push their own agendas. If necessary they
> should discuss their summaries with members of both/all sides of a given
> discussion and with members of the core group.

It would be helpful if people commented on the stuff already there and
said if it's good, bad or otherwise.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout wrote:
> On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote:
>> I agree pretty much. However I disagree that a wiki is not useful to
>> summarize discussion from the mailinglist. All that it needs is people
>> that are humble and do not push their own agendas. If necessary they
>> should discuss their summaries with members of both/all sides of a given
>> discussion and with members of the core group.
>
> It would be helpful if people commented on the stuff already there and
> said if it's good, bad or otherwise.

I just looked through the wiki. Generally I like whats there. It seems
the approach taken is essentially that the unofficial todo items contain
a current brain dump on the steps taken so far, the status and future
work. So if any "busy bees" would want to join in and help, they would
just keep close contact with the person that is working on the todo
item. I think this is a great basis to make it easier for other people
to join in and should be a solid basis for turning this into "official"
todo items.

The ICU todo item will maybe also become a good test bed for how to
build up a document at the very early stages, where there will still be
a lot of discussions on the mailinglists.

Thinking a head (and maybe too far then we really need to at this
point): So how will this work once they become "official". I assume
Bruce's todo list would then link to the wiki and the editing would
become more conservative? Would the status get frozen? I assume that if
the given functionality is expanded/changed in future releases then it
would be done in the same document? Or would a new document be startet
to detail the new development process that would simply optionally list
previous documents?

regards,
Lukas

On Tue, Sep 19, 2006 at 06:52:59PM +0200, Lukas Kahwe Smith wrote:
> Thinking a head (and maybe too far then we really need to at this
> point): So how will this work once they become "official". I assume
> Bruce's todo list would then link to the wiki and the editing would
> become more conservative? Would the status get frozen? I assume that if
> the given functionality is expanded/changed in future releases then it
> would be done in the same document? Or would a new document be startet
> to detail the new development process that would simply optionally list
> previous documents?

Unsure. I know twiki has the possibility to add a tag to a page that
restricts the users that can edit a page. I assume the same could be
used here somewhere, though I am unsure how.

I'm not sure it's a real problem though. What's the risk? That someone
will add something to the wiki that confuses people? At the end of the
day it's the patch that gets reviewed, not the wiki page. Once the
patch is in it's just historical interest I guess...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Hi, Martijn,

Martijn van Oosterhout wrote:

> 2. I can see the official todo list being in CVS, which gives it all
> the access protection it needs. A wiki todo list can stay where it is,
> just that it's not official.
>
> [I've just made a reference to the TODO list in CVS from the wiki, that
> should help].

Maybe you should rename the public writable Wiki page list to Wishlist
instead of Todo, to make the difference more explicit.

Thanks,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

On Wed, Sep 20, 2006 at 12:28:54PM +0200, Markus Schaber wrote:
> Maybe you should rename the public writable Wiki page list to Wishlist
> instead of Todo, to make the difference more explicit.

Hmm, all the stuff there now does refer to things that are on the TODO
list (I think). So it's not wishlist at all, it's the *detail* that's
unoffical.

But you're right, it'd probably be a good idea to make a section for
absolutly wishlist stuff. I just can't think of any right now, the TODO
list is quite extensive.

In any case I've altered the wording a bit to make the distinction a
bit clearer.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Dave Page wrote:
> I have now moved the wiki installation to:
>
> http://developer.postgresql.org/

BTW: I am wondering if there is an RSS feed of the changes?

On my wiki I have an RSS feed for every page, subwiki (aka area) and the
entire wiki people can subscribe to:
http://oss.backendmedia.com/rss.php?area=PHPTODO&page=HomePage
http://oss.backendmedia.com/rss.php?area=PHPTODO
http://oss.backendmedia.com/rss.php

regards,
Lukas

On Wed, 27 Sep 2006, Lukas Kahwe Smith wrote:

> Dave Page wrote:
> > I have now moved the wiki installation to:
> >
> > http://developer.postgresql.org/
>
> BTW: I am wondering if there is an RSS feed of the changes?
>
> On my wiki I have an RSS feed for every page, subwiki (aka area) and the
> entire wiki people can subscribe to:
> http://oss.backendmedia.com/rss.php?area=PHPTODO&page=HomePage
> http://oss.backendmedia.com/rss.php?area=PHPTODO
> http://oss.backendmedia.com/rss.php

I only really know of the entire wiki one, but that's the only one I have
ever wanted to do. I think it may be able to limit to namespaces, but I
am not sure about that.

http://developer.postgresql.org/index.php?title=Special:Recentchanges&feed=rss

There are a bunch of knobs on the Special:Recentchanges page which could
apply also to the rss version, but I have never tried it and they may not,
I don't know.

>
> regards,
> Lukas
>

--
Besides the device, the box should contain:

* Eight little rectangular snippets of paper that say "WARNING"

* A plastic packet containing four 5/17 inch pilfer grommets and two
club-ended 6/93 inch boxcar prawns.

YOU WILL NEED TO SUPPLY: a matrix wrench and 60,000 feet of tram
cable.

IF ANYTHING IS DAMAGED OR MISSING: You IMMEDIATELY should turn to your
spouse and say: "Margaret, you know why this country can't make a car
that can get all the way through the drive-through at Burger King
without a major transmission overhaul? Because nobody cares, that's
why."

WARNING: This is assuming your spouse's name is Margaret.
-- Dave Barry, "Read This First!"

> > I have now moved the wiki installation to:
> >
> > http://developer.postgresql.org/
>
> BTW: I am wondering if there is an RSS feed of the changes?

There is.
http://developer.postgresql.org/index.php?title=Special:Recentchanges&fe
ed=rss

//Magnus