Re: Commitfest namespacing (was: TODO, FAQs to Wiki?)

On Sun, Apr 20, 2008 at 1:45 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Bruce Momjian wrote:
> > I am impressed at the state of the May wiki patch queue:
> >
> > http://wiki.postgresql.org/wiki/CommitFest:May
> >
> > It is even tracking the psql wrap patch I am working on now.
>
> Thanks. We've put a certain amount of effort on it. Credit for the
> templating system goes to Brendan Jurd, who implemented the way to make
> it display as tables but without the messy markup. I think the
> templates that are now in place make for a reasonably comfortable
> environment. Not as simple as editing a plain text file, but I expect
> it is lean enough.

I appreciate your positive comment Bruce. Credit must also go to
Alvaro for supplying valuable feedback and encouragement offlist while
I worked on those templates =)

I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in 2009/2010/etc., the history
of the May 2008 CommitFest will still be easily viewable as a discrete
item.

Thoughts?

Cheers,
BJ

Brendan Jurd escribió:

> I wonder if we should namespace the CommitFest pages by year as well
> as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
> even after we've had a CommitFest:May in 2009/2010/etc., the history
> of the May 2008 CommitFest will still be easily viewable as a discrete
> item.

Agreed -- this same idea occurred to me some days ago, but I then forgot
it :-) For now, it would be good to ensure that CommitFest:May is a
redirect to May2008. (I think it would make sense to have a
CommitFest:Current redirect and perhaps CommitFest:Next.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Brendan Jurd escribió:
> > I wonder if we should namespace the CommitFest pages by year as well
> > as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
> > even after we've had a CommitFest:May in 2009/2010/etc., the history
> > of the May 2008 CommitFest will still be easily viewable as a discrete
> > item.
>
> Agreed -- this same idea occurred to me some days ago, but I then forgot
> it :-) For now, it would be good to ensure that CommitFest:May is a
> redirect to May2008. (I think it would make sense to have a
> CommitFest:Current redirect and perhaps CommitFest:Next.)
>

We may need to draw some kind of distinction between the "open"
commitfest (which is where developers should submit new patches) and
the "current" commitfest (which is where reviewers should be directing
their attention).

There'll be a substantial time period where the "open" and "current"
commitfests are the same thing, but, for example, when the May
commitfest closes for new submissions, it will still be the "current"
commitfest, but will no longer be the appropriate place for developers
to post their new patches (that will become July).

I've started thinking of a commitfest as moving through the following
stages in its lifetime:

1. Future
2. Open for submissions
3. In progress (closed for submissions)
4. Complete

We probably need to have the following redirects in place:

* CommitFest:Current (for reviewers)
* CommitFest:Open (for submitters)
* CommitFest:Next

Suggestions for alternative (less ambiguous) nomenclature are welcome ...

Cheers,
BJ

Brendan Jurd wrote:
> On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>
>> Brendan Jurd escribió:
>> > I wonder if we should namespace the CommitFest pages by year as well
>> > as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
>> > even after we've had a CommitFest:May in 2009/2010/etc., the history
>> > of the May 2008 CommitFest will still be easily viewable as a discrete
>> > item.
>>
>> Agreed -- this same idea occurred to me some days ago, but I then forgot
>> it :-) For now, it would be good to ensure that CommitFest:May is a
>> redirect to May2008. (I think it would make sense to have a
>> CommitFest:Current redirect and perhaps CommitFest:Next.)
>>
>>
>
> We may need to draw some kind of distinction between the "open"
> commitfest (which is where developers should submit new patches) and
> the "current" commitfest (which is where reviewers should be directing
> their attention).
>
> There'll be a substantial time period where the "open" and "current"
> commitfests are the same thing, but, for example, when the May
> commitfest closes for new submissions, it will still be the "current"
> commitfest, but will no longer be the appropriate place for developers
> to post their new patches (that will become July).
>
> I've started thinking of a commitfest as moving through the following
> stages in its lifetime:
>
> 1. Future
> 2. Open for submissions
> 3. In progress (closed for submissions)
> 4. Complete
>
> We probably need to have the following redirects in place:
>
> * CommitFest:Current (for reviewers)
> * CommitFest:Open (for submitters)
> * CommitFest:Next
>
> Suggestions for alternative (less ambiguous) nomenclature are welcome ...
>
>
>

Why not use a form for posting new patches that would automatically put
it on the right page? (I have no idea if you can do that sort of thing
using mediawiki - it's just what I would do if I were designing a patch
submission system from scratch).

cheers

andrew

On Tue, Apr 22, 2008 at 2:44 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> Why not use a form for posting new patches that would automatically put it
> on the right page? (I have no idea if you can do that sort of thing using
> mediawiki - it's just what I would do if I were designing a patch submission
> system from scratch).
>

Well at that point you're basically talking about using a patch tracker =)

As a matter of fact, I'm hoping that managing commitfests via the wiki
will demonstrate what patch tracking can bring to the project, as well
as help illuminate what we would actually require from patch tracking
software. There's been a lot of conjecture on that topic, but putting
the wiki into practice might give us some real empirical results to
mull over.

Being able to submit patches via a web form is one of the more obvious
benefits of a real patch tracker. I'm not aware of any way to
accomplish this in mediawiki without resorting to some nasty script
hackery.

Cheers,
BJ

On Tue, 22 Apr 2008, Brendan Jurd wrote:

> I wonder if we should namespace the CommitFest pages by year as well
> as month (i.e., move CommitFest:May to CommitFest:May2008).

This already came up on pgsql-www and as I just replied to over there, the
current structure has some things I'd like to fix beyond just this (and
there's a pending namespace vs. categories argument brewing there).
That's the list where this sort of thing will get hashed out at. Please
come join so you can get sucke...err, volunteer to help out even more than
you already have.

> This way, even after we've had a CommitFest:May in 2009/2010/etc., the
> history of the May 2008 CommitFest will still be easily viewable as a
> discrete item.

There ultimately should be pages for "CommitFest:2008" and
"CommitFest:8.4" that the Wiki generates itself. I'd prefer not to see
any band-aid changes made in this area that aren't thinking forward to
address those as well. Work on improving the structure for May instead
like you've been doing, that's much more valuable right now IMHO.

> We probably need to have the following redirects in place:
> * CommitFest:Current (for reviewers)...

Ditto here. I already intend to eliminate the CommitFest redirect you've
put there already and replace it with a page listing the "Views" available
one day, and I'd prefer not to see more of these floating around.

Redirects are designed to be a useful hack when a page gets removed or to
handle common shortcuts/errors. In general, if you're relying on them
heavily for external navigation structure, you're probably not using the
right tool for that sort of job.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On Tue, 22 Apr 2008 02:54:16 +1000
"Brendan Jurd" <direvus(at)gmail(dot)com> wrote:

> Being able to submit patches via a web form is one of the more obvious
> benefits of a real patch tracker. I'm not aware of any way to
> accomplish this in mediawiki without resorting to some nasty script
> hackery.

We could probably put the form "in front" of mediawiki and have it
autocreate a new page under some other page etc...

But then again... there is already perfectly could tracking software
out there.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Brendan Jurd wrote:
> I wonder if we should namespace the CommitFest pages by year as well
> as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
> even after we've had a CommitFest:May in 2009/2010/etc., the history
> of the May 2008 CommitFest will still be easily viewable as a discrete
> item.

Yep, makes sense. Actually you can use '2008-05' so they sort properly.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escribió:
> Brendan Jurd wrote:
> > I wonder if we should namespace the CommitFest pages by year as well
> > as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
> > even after we've had a CommitFest:May in 2009/2010/etc., the history
> > of the May 2008 CommitFest will still be easily viewable as a discrete
> > item.
>
> Yep, makes sense. Actually you can use '2008-05' so they sort properly.

Perhaps we should add a category "commitfest" (already there) and then
subcategories "2008", "2009", etc.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support