One way would be to categorise areas and sub-areas and have a clear indication, where the work has not been done.
So that if I came to such place, I could find the sub-topic that I am interested in with clear indication of the status. > On 5 Jul 2023, at 21:48, Brendan Barnwell <brenb...@brenbarn.net> wrote: > > On 2023-07-04 17:21, Christopher Barker wrote: >> Anyway, I'd love to hear your thoughts on these ideas (or others?) - both >> technical and social. > > To my mind there are two interrelated social problems that make this > task difficult: > > 1) Promulgating a list of "good" packages tends to make people think packages > not on the list are not good (aka "implied exhaustiveness") > 2) In order to curate all or nearly all packages, you need curators with a > wide range of areas of interest and expertise (aka "breadth"). > > The reason these are interrelated is that once people start thinking > your list is exhaustive, it's really important to have breadth in the > curation, or else entire domains of utility can wind up having all packages > implicitly proscribed. > > As an example, a few months ago I wanted to do some automated email > manipulations via IMAP. I looked at the builtin imaplib module and found it > useless, so I went looking for other things. I eventually found one that > more or less met my needs (imap_tools). > > The question is, what happens when a person goes to our curated index > looking for an IMAP library? If they don't find one, does that mean there > aren't any, or there are but they're all junk, or just that there was no > curator who had any reason to explore the space of packages available in this > area? In short, it becomes difficult for a user to decide whether a tool's > *absence" from the index indicates a negative opinion or no opinion. > > There are ways around this, like adding categories (so if you see a > category you know someone at least attempted to evaluate some packages in > that category), but they can also have their own problems (like increasing > the level of work required for curation). I'm not sure what the best > solution is, but just wanted to mention this issue. > > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no path, > and leave a trail." > --author unknown > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/WYLHRIBIRKP6W3HGCGFJGYHDL3GCSOR2/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O233MP5I5MJLTTVK7FRIKJPD6736R3KX/ Code of Conduct: http://python.org/psf/codeofconduct/
