So, I had intended to spend some time on this at least three times a year. I've clearly failed at that, but now is as good a time as any to pick it back up again.
Over in [1], Tom opined: > John Naylor <john.nay...@enterprisedb.com> writes: > > > "WARNING for Developers: Unfortunately this list does not contain all the > > information necessary for someone to start coding a feature. Some of these > > items might have become unnecessary since they were added --- others might > > be desirable but the implementation might be unclear. When selecting items > > listed below, be prepared to first discuss the value of the feature. Do not > > assume that you can select one, code it and then expect it to be committed. > > " > > I think we could make that even stronger: there's basically nothing on > the TODO list that isn't problematic in some way. Otherwise it would > have been done already. The entries involve large amounts of work, > or things that are subtler than they might appear, or cases where the > desirable semantics aren't clear, or tradeoffs that there's not > consensus about, or combinations of those. > > IME it's typically a lot more productive to approach things via > "scratch your own itch". If a problem is biting you directly, then > at least you have some clear idea of what it is that needs to be fixed. > You might have to work up to an understanding of how to fix it, but > you have a clear goal. I've come up with some revised language, including s/15/16/ and removing the category of "[E]" (easier to implement), since it wouldn't be here if it were actually easy: -- WARNING for Developers: This list contains some known PostgreSQL bugs, some feature requests, and some things we are not even sure we want. This is not meant to be a resource for beginning developers to get ideas for things to work on. <WIP: maybe direct them to commitfest?> All of these items are hard, and some are perhaps impossible. Some of these items might have become unnecessary since they were added. Others might be desirable but: - a large amount work is required - the problems are subtler than they might appear - the desirable semantics aren't clear - there are tradeoffs that there's not consensus about - some combinations of the above If you really need a feature that is listed below, it will be worth reading the linked email thread if there is one, since it will often show the difficulties, or perhaps contain previous failed attempts to get a patch committed. If after that you still want to work on it, be prepared to first discuss the value of the feature. Do not assume that you can start coding and expect it to be committed. Always discuss design on the Hackers list before starting to code. Over time, it may become clear that a TODO item has become outdated or otherwise determined to be either too controversial or not worth the development effort. Such items should be retired to the Not Worth Doing page. [D] marks changes that are done, and will appear in the PostgreSQL 16 release. -- We could also revise the developer FAQ: - remove phrase "Outstanding features are detailed in Todo." - add suggestion to to check the Todo or Not_worth_doing pages to see if the desired feature is undesirable or problematic - rephrase "Working in isolation is not advisable because others might be working on the same TODO item, or you might have misunderstood the TODO item." so it doesn't mention 'TODO' at all. [1] https://www.postgresql.org/message-id/415636.1673411259%40sss.pgh.pa.us -- John Naylor EDB: http://www.enterprisedb.com
