Re: cutting down the TODO list thread

On Mon, Jan 30, 2023 at 01:13:45PM +0700, John Naylor wrote:
> On Tue, Jan 24, 2023 at 11:57 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I think we just point them at the TODO list and they will read the top
> > of the list first, no?  I think you are right that we updated the top of
> > the TODO but didn't update the places that link to it.  I am thinking we
> > should just trim down the text linking to it and let the top of the TODO
> > list do its job.
>
> Okay. How about:
>
> "It's worth checking if the feature of interest is found in the TODO list on
> our wiki: http://wiki.postgresql.org/wiki/TODO. The entries there often have
> additional information about the feature and may point to reasons why it hasn't
> been implemented yet."

Good.

> > Wow, I would not send a new person to the SQL standard docs.  ;-)  I am
> > thinking we just don't have a good answer to this so let's say less.
>
> Do I understand right that we could just remove this entire section "What areas
> need work?"?

Yes, I think so.

> > > 2)
> > > from:
> > > "What do I do after choosing an item to work on?
> > >
> > > Send an email to pgsql-hackers with a proposal for what you want to do
> > > (assuming your contribution is not trivial). Working in isolation is not
> > > advisable because others might be working on the same TODO item, or you
> might
> > > have misunderstood the TODO item. In the email, discuss both the internal
> > > implementation method you plan to use, and any user-visible changes (new
> > > syntax, etc)."
> > >
> > > to:
> > > "What do I do after choosing an area to work on?
> > >
> > > Send an email to pgsql-hackers with a proposal for what you want to do
> > > (assuming your contribution is not trivial). Working in isolation is not
> >
> > Can new people identify trivial?
>
> I'd say they have some idea about that, since we do regularly get typo fixes
> and doc clarifications. Sure there is some grey area, but I don't think the
> dividing point is important. The important thing is, we also sometimes get
> large and invasive patches without design discussion, which we want to
> discourage.

Agreed.

> > I can now see that just removing the [E] label totally is the right
> > answer.  Yes, there might be an easy item on there, but the fact we have
> > three labeled and they are not easy makes me thing [E] is causing more
> > problems than it solves.
>
> Okay, having heard no objections I'll remove it.

Thanks.

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

Embrace your flaws. They make you human, rather than perfect,
which you will never be.