I added on to this on another e-mail thread, however, it got no response, specially because I didn't have an e-mail to reply to, so I am copy and pasting the messages here. ‐‐‐‐‐‐‐ E-mail one ‐‐‐‐‐‐‐ First and foremost, there is a saying in Brazil that goes by as "an empty bag never holds itself standing", so always remember to care for yourself, eat a snack, drink fluids of your choice (from tea, water and coffee to soup and porridge), rest a little, stop doom scrolling social media and so on. Second, want to address the giant essay by Emily Shaffer (aka: Review process improvements) and give my opinions on some of the points made. Third, sorry for the botched response, but I wasn't on the mailing list before the mail was posted, so couldn't directly respond the message. Addressing point #1, titled "Draft a MAINTAINERS file": seems quite reasonable, I would also like to address some matters about this, first is that there is no point of contact for "trusted sources" within the git project and it is quite negative for historical purposes, because maintainers and more prolific parties will inevitably retire or move on from Git themselves and their prestige won't be recorded beyond their commit history within the project and it might lead to their contributions being forgotten. Second is that it is hard to know who is responsible to what from the get go without being in the know already. Third, please make all entries on any and such file that might auto send messages non-committal, why? Nobody wants to receive a message from a third party that the git mailing list deems "trustwothy" only for it to be some scam of sorts that only happened because a modification to the file managed to fly under the radar, so make it a one way pass and all tags are only to people, not from. Fourth, I, personally, only want to partake on discussions, but barely want to see patches and commits, maybe allow for some sot of group inheritance and group message allow or deny lists? So people that don't want patches don't receive patches, but they can filter to receive only "memory allocation" topics, but they won't receive patches that are for memory allocation, because the "patches" and "discussion" topics take higher system priority than the "memory allocation" topic, be it user by user or system wide. Maybe also auto-filter messages, even in a dumb way or in a sender dependant way. Addressing point #2, titled "Draft a ReviewingPatches doc", and point #3, titled "Google Git team will review cover letters and commit messages internally before sending series to the list": not much to say beyond, people, share your reviewing know how, including you Google folks, if you interpret the reviewing process as an algorithm, it would make sense that all mechanisms of human interaction and review to be shared as part of the code base. So please, Google people, share what and how you do your reviews. It is also a matter of security, if your review process isn't transparent, we can't know whether we can trust everything you provide, because you might be leaving or dismissing problems and it might fly under the radar or malicious action could be taken and, since the group as a whole is already trusted, some malicious code could be included, even if it is not explicitly so. Addressing point #4, titled "Documentation changes to encourage commit message quality": This isn't stressed enough in many Git tutorials and the like, and it should, the commit messages are for the journaling of changes, so you or third parties can understand the thought process behind changes and not feel like headless chickens running around a barn whenever you attempt to understand what has been done, maybe addressing it on the source code of git and its documentation might help address this topic. Extra notes: As a person with ADHD, REAMEs can be daunting at times, specially when they are boring word walls, and they can be incomplete or repetitive if there are other documents addressing information contained within them, maybe reference files such as "Contributing.md" instead of copying them verbatim? An example would be "To read more on how to contribute to projects, read 'Contributing.md'." instead of what is information contained within "Contributing.md", it would help a lot with human to human interactions. Thanks for the attention, take care! João Victor Bonfim (any pronouns). ‐‐‐‐‐‐‐ E-mail two ‐‐‐‐‐‐‐ To address Junio Hamano's comment: > But don't spend too much time on it to waste your momentum. Having > sounding board in your buddies is much better than not having any, > but your buddies may already share too much background context with > you to blind them from noticing why it is unclear to outsiders. Maybe ask someone like your mom, dad, aunt, cousin, long past college acquaintance to comment on the commit/log/patch comment itself and maybe also the code published? It might me more helpful the less they understand about code or are knowledgeable about your personal quirks. João Victor Bonfim (any pronouns). ‐‐‐‐‐‐‐------------‐‐‐‐‐‐‐ Yes, I know I wrote an essay-esque message myself. It was a lot. Hope it helps to move the conversation along. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Em segunda-feira, 20 de dezembro de 2021 às 14:14, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> escreveu: > On Mon, Dec 20, 2021 at 7:27 AM Ævar Arnfjörð Bjarmason > > avarab@xxxxxxxxx wrote: > > > Whereas the only cases that really applies to in git.git (and I think it > > > > might be useful to have a MAINTAINERS for these) are: > > > > # but not all of po/, see caveats in po/README etc. > > po/ -> https://github.com/git-l10n/git-po/ > > # Pulled from their respective upstreams > > {gitweb,git-gui}/ > > # Anyhing else I'm missing? Maybe {sha1dc,sha1collisiondetection}/*? > > > > > > We should be leaning into helper scripts like > > > > contrib/contacts/git-contacts (and I'm aware of some out-of-tree "better > > > > git-contacts", but have not used them myself). > > For completeness, the granddaddy of out-of-tree "better" tools is > > Felipe's git-related[1], which is maintained and more functional. > > [1]: https://github.com/felipec/git-related
