Szymon,
* Szymon Lipiński (mabewlun@gmail.com) wrote:
> a couple of days ago I was reading through the tickets in the Django bug
> tracker. It was much easier to find any information about the things to
> work on than currently for Postgres.
I tend to doubt that a bug tracker would change that situation.
> >From my point of view, for Postgres, there is just a not updated too often
> list of things to implement on the wiki. If I need to find some additional
> information, then I can find there just some links to mails from the mail
> groups.
As far as 'new features' go, I don't know that we'd put those on the bug
tracker anyway. Perhaps some of them should go on the todo list, such
as the discussion around restrictive RLS policies, but the canonical
list is really developer oriented and less project oriented. That's
probably not a good thing, but I don't think trying to use a bug tracker
to track features is the answer there either.
I will say that something easier than the todo list (aka the wiki) to
work with would be nice for tracking new feature thoughts.
> Then I need to read through the emails. This is not user friendly too, as I
> need to click through the email tree, and if an email has multiple replies,
> it is usually hard not to omit some of them, as after going into a reply, I
> need to click to get to the parent mail again.
This is solved by the 'flat' view, which gives you a single page with
all emails for the thread. Go to any email in the archives and click on
'flat', at the end of the Message-ID line.
> What's more, there are some things on the wiki, and when I asked about
> that, it turned out that "oh, there was some discussion long time ago, that
> it is not doable".
Right, that's one of the challenges with the current todo list.
> It would be also worth storing the information that someone is working on
> something, so the work won't be doubled.
Thankfully, that doesn't seem to happen too much in this community as we
all communicate a fair bit. I agree that risk exists, but I don't
believe it's a reason for a bug or feature tracker by itself.
> Personally I'd also change sending patches in emails to github pull
> requests :).
Don't get your hopes up.
> ... or maybe the difference is more in the data structure, the email
> discussion is a tree (with a horrible interface to the archive) while in a
> bug tracker, the discussion is linear, and easier to follow.
The interface is entirely open source and I'm sure Magnus would be
happen to hear specific ideas for improvement, or, even better, pull
requests. :)
Thanks!
Stephen
