On Tue, Jan 24, 2023 at 11:57 PM Bruce Momjian <br...@momjian.us> wrote: > > On Tue, Jan 24, 2023 at 10:46:34AM +0700, John Naylor wrote: > >
> > https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F#TODOs > > to: > > "It's worth checking if the feature of interest is found in the TODO list on > > our wiki: http://wiki.postgresql.org/wiki/TODO. That list contains some known > > PostgreSQL bugs, some feature requests, and some things we are not even sure we > > want. Many entries have a link to an email thread containing prior discussion, > > or perhaps attempts that for whatever reason didn't make it as far as getting > > committed." > > > > ...which might make more sense if moved below the "brand new features" section. > > 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." > > -- > > https://wiki.postgresql.org/wiki/Developer_FAQ > > > > 1) > > from: > > "What areas need work? > > Outstanding features are detailed in Todo. > > > > You can learn more about these features by consulting the archives, the SQL > > standards and the recommended texts (see books for developers)." > > > > to: > > ??? -> For "what areas need work?", we need to have a different answer, but I'm > > not sure what it is. > > 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?"? > > 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. > 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. -- John Naylor EDB: http://www.enterprisedb.com
