Add some rough notes from the inclusion summit
Further edits to these can happen collaboratively to flesh them
out more.
Link: https://code-review.googlesource.com/id/I8f8a79d1193d9fb46cfc15ff5ccbde91453cb796
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
diff --git a/notes.md b/notes.md
new file mode 100644
index 0000000..0297d68
--- /dev/null
+++ b/notes.md
@@ -0,0 +1,458 @@
+**DAY 1**
+
+What do I want to get out of the summit?
+
+* Action Items for the entire core community to make this project a bit more welcoming. Not to contributors, but to users.
+* To hear what others are experiencing, to discuss ways to improve things.
+* To get initial, actionable next step to identify inclusion
+* To figure out whether we can learn from other Open Source communities
+* To learn more about the git community
+* Find out how things can be better for other open source projects
+* Steps git project can take to make the contributor community more diverse
+* We're clear about our goals, but we are out of touch with our users and what they need. Want to make progress towards this.
+* Show up and listen and see what others are interested in.
+* How to make Git an easier tool to use and contribute to
+* Helping people who are not like us
+* Learn what difficulties people have with git (both the software and community)
+* Making sure user are included, making sure we don't lock out newer generation of users with older tool
+* Interested learning about more peoples' experiences, how to make things more inclusive
+* Interested to hear what users would like
+* How to make the project more inclusive
+* How to grow open communities and communities in general
+* Learn about challenges and difficulties encountered in open source communities
+
+Scenario: You are trying to diversify the open source community. As a part of your work, you attend a conference and connect with a number of new people. Two people mention interest in becoming developers, but have little or no experience. What do you do?
+
+Validate the interest, try to gauge where they could be motivated.
+
+Open offers don't work as well. Offer specific examples: "I can introduce you to some folks who might also be good to work with". Point to specific programs.
+
+https://opensource.guide/how-to-contribute,
+`good-first-contributions` tags in bug trackers.
+
+If they have no coding experience, suggest documentation changes.
+
+Remember that taking your first few steps in a project can be hard. Warm introductions help. Imposter syndrome is real.
+
+Overwhelm them with my enthusiasm. :-P "Let's jump on a meeting, talk it out while you're working through it."
+
+Be honest about who you are as a mentor
+
+Scenario: A new open source developer has joined your community. You've been chatting and they come out to you as trans. You notice their deadname is used in version control history. What do you do?
+
+"I notice your former name is used here". If they've misconfigured their client, you can help them with configuring it and with how to submit a mailmap entry.
+
+If it's in earlier history, I'd just ignore that it's there and pretend it doesn't exist.
+
+This can be hard in maintaining a reputation based on earlier work. You can't claim historic work to be yours without creating the association between names.
+
+Mailmap avoids exposing a deadname to people casually browsing, but the raw commit object contains the deadname as part of the auditable history.
+
+Let the person direct the way they would like you to support them. They might know and not care. They may not have come out more widely as trans. Acting hastily without checking in first can hurt more than it helps.
+
+General principles:
+
+* Confidentiality
+* Center on the affected person's wishes and assume empowerment (agency)
+* Make an explicit offer of support
+* Only afterward, work toward a structural solution.
+
+Some tooling improvements would really help.
+
+Scenario: In a casual conversation, three software developers tell you that they are having trouble debugging some open source software. When they put in pull requests, they are regularly denied by the project owners. The three people with this issue identify as women and their avatars are clearly feminine. What do you do?
+
+Ask questions, be a witness. "This hasn't been merged and it's valuable, is this something I can help with?"
+
+Validate the contribution. Suggest different ways you could get involved and let the developers pick what option to move forward with.
+
+Understand the problem first. What is the project's process for contributing code?
+
+What leverage or sway do you have as a person who hears these stories? If I'm a maintainer, I might want to figure out what's going on and get it resolved at its root.
+
+Were there reasons cited for rejecting the contributions? What structural change should take place, do we need to review the rules of contributing (contribution file, CoC file), to make it more equitable? Move from "I don't like this change" to something more concrete. What are your values as a community?
+
+Do the engineers have other avenues to help? Maybe they work for a company and their employer can pull their weight.
+
+There might be a style disconnect.
+
+In academic pre-publication review processes, using rubrics has been helping with reducing bias.
+
+**DAY 2**
+
+Breakout #1
+
+**The Mailing List - Inclusive project communication**
+
+Brian M. Carlson: discussion leader
+
+Dscho often critiques the mailing list-focused approach. But some things work well:
+
+- Central spot, no-one can miss anything, theoretically
+
+- You can join the mailing list through most email address vendors (Hotmail bounces though), open
+
+- High-quality, considerate language
+
+- Asynchronous for people to parse at their own time
+
+- Email lends itself for long-form, elaborate communication vs chat
+
+- The archive is useful
+
+- The ability to search
+
+Plain text could be a barrier as it requires special setup in virtually all clients, and in long-form might be difficult for people to parse.
+
+Email from addresses ending in @outlook.com is bounced.
+
+What are the pain points?
+
+- Established style, yet there doesn't appear to be documentation on these conventions
+
+- Spam gets through the Git mailing list
+
+- Lack documentation for setup for different email clients, or not visible - regardless it's a high barrier of entry, a lot to ask of people to train themselves in the way of the mailing list first
+
+- Documentation on git-scm.com with the mailing list sign up link
+
+We expect emails to be well-formatted but don't recognize what we're asking of first time contributors. They're not likely to get it right on their first try. It's incredibly daunting for non-native English speakers as well, I can imagine.
+
+It was mentioned that StackOverflow is an easier place to report bugs than the mailing list.
+
+Shoutout to GitGitGadget (GGG) which helps folks format their patch submission.
+
+We're missing great people because the first patch people might contribute might not make the mark.
+
+Very different from a Discourse server where you'd assign moderators who can stop people from participating. Stuff filters out because maintainers ignore comments - cause they'd still come in. Do we even want to ban someone from the list?
+
+Noticed some new characters post to the mailing list around high-profile topics, like the master/main discussion.
+
+Dscho shared that the discussion on the mailing list was mild compared to what he encountered in the Git for Windows issue tracker on GitHub where there was a lot of toxic behavior, requiring him to even step away for a bit.
+
+Effective moderation tools, and auditing / better onboarding documentation seem to be the 2 main things that would benefit the mailing list in terms of accessibility.
+
+Making it easier for level 0 contributors is making it easier for bad actors as well.
+
+Take a position of "Stringent in output, lenient in input" (Postel's Law), focus on the idea of the patch, rather than standards-met? That would put a lot of strain on a maintainer, and would only be possible if there's a larger maintainer team / educated people to be (helpful) on a reviewing team, etc.
+
+Go(lang) reviews the code, not whether it meets the convention, rather just fix style in triaging. Reviewing in rotation, have automated a bunch of things as well.
+
+A snowpatch server provides a place to put some automated comments. Automated linting might be something to look into (or to add to GGG as CI). Stolee tried setting something like that up in an internal Azure Repo (it turned every `[PATCH]` mail into a PR), but discontinued that practice due to the sheer volume.
+
+Having a guide for reviewers could be useful to document expectations
+
+**Pair programming and mentorship**
+
+* De facto standard of the `Co-Authored-By` trailer
+ * GitHub shows the Co-Authored-By avatars alongside the author
+ * that said, there's no "git commit --coauthor", “git log --author”, doesn't show up in shortlog
+ * trailer system exists but is hard to use
+ * some complexity is inherent because many trailers are project-specific
+ * git log --format='%h %s%nAuthor: %an <%ae>%n Co-author: %(trailers:valueonly,key=Co-authored-by)'
+ * Where does Git parse and surface trailers?
+ * Peff mentions patches a long time ago for shortlog to group by arbitrary trailers
+ * interpret-trailers lets you rewrite and modify trailers, can ask it to dump them in normalized, parsed form. There's also a trailers placeholder in "git log" formatter
+* Pair programming experiences
+ * Stolee has found pair programming to be helpful, both sync using VSCode Liveshare and async using pre-review before it hits the mailing list. Getting coauthorship has never been important to him
+ * Others' experiences here match, so why are users finding this lack of feature important?
+ * Can affect career advancement (promotion, bonuses)
+ * Management's view might not accurately reflect a person's contribution
+ * One contributor getting the recognition, another getting nothing
+ * We're used to a high-trust environment. For someone in a marginalized group in a lower-trust environment, can our tool help them?
+ * Academia seems to have high stakes around authorship
+ * Stolee: in math (combinatorics), clear conventions:
+ * Every author is equal, and you always order alphabetically.
+ * Anyone who helped you, you always include unless they opt out. If they didn't help enough, you just don't work with them again.
+ * If you can make it something that pervades the culture, people stop looking at order to see what matters
+ * In hard sciences there can be something more formal
+ * Philip: paper on black hole imaging with two whole pages of contributors
+ * If you have native support for multiple authors, may want a range of ways to use it, including that ordering matters
+ * Complexity around sorting order --- sort by family name?
+ * Author is in the commit object is “first”, other authors are in an order in the commit message
+ * Jonathan: sounds like the least opinionated thing we can do is add more support for the existing co-Authored-By convention
+* Supporting distanced work, being decentralized helps
+ * Review of changes as slow-motion pair programming
+ * We often assume people should be gifted individuals producing amazing patches all in one go
+ * Sending patches to squash in
+ * When in an awkward moment, not sure how to get out of it, not sure how to get someone to give you a hand. half-completed patch, initial try, got some comments
+ * May not feel safe to ask for help, can see that as a problem for newer contributors
+ * It's hard to make people understand they shouldn't spend a lot of time before asking a question
+ * With some experience, you can guess quite fast and after a short amount of time you get a good mentor/student working interaction
+ * Phrases to say "this is a phrase you can put in to say at this point this is what you need"
+ * Example: provided a stock phrase "are we taking a break, then" when someone was asked to bring in tea and ended up excluded from discussion
+ * Culturally, how do we make sure we convey "here's how to ask for help"
+ * Junio: Should I start pinging "stalled" topics a lot sooner?
+ * It can put people on the spot, private pings may work better
+* How can we find more mentors and support mentoring?
+ * Christian: I've been trying to ask people who get a mentor to co-mentor for outreachy and gsoc after their internship
+ * It may be tempting to try to get everything perfect with coding style when the contributor wanted "is this even a good idea?" Building empathy, understanding what the contributor is looking for
+ * Markers like PATCH/RFC, PATCH/WIP, etc may not be known by all contributors
+ * With timezones want to avoid wasting review rounds, but sometimes need to rein that instinct in to give the contributor a chance to figure things out
+ * Other side of the token: with asynchrony, when you get feedback, it's not always immediately clear. Frustration of needing another round to get it clarified
+ * The more specific review feedback is, the more likely it is to land correctly and produce a good outcome.
+ * The absolute best would be "I just rewrote your patch and here's a diff doing those things" but reviewers have limited time
+ * "I think it's probably this direction, and you can try that and it may be the wrong direction"
+ * Making clear how much you thought through what you're suggesting
+ * Junio: yes, making that clear is very important to avoid misleading inexperienced contributors
+ * Jonathan: quick plug for "git evolve" idea as something a little smoother than the “fixup patch” workflow.
+
+**accessibility and localization**
+
+* Localization, localization of contributor onboarding docs (e.g. Arabic)
+* Inclusion-aware design process
+ * How do we ensure new features have the effect we want for marginalized groups instead of only working well for populations already well represented in the project? How do we take into account visual and motor disabilities, differences in understanding of language, different roles in projects that different users will have?
+
+Localization:
+
+* We have a localization library, which translates only user visible strings
+* What's the process for adding localizations?
+* There is a dir in git project with string mappings (po/)
+* There's been some work on translating manpages: https://lore.kernel.org/git/1979608.xhrAu3A07H@cayenne/. Developer documentation is not being translated at all
+* Can non-technical people provide translations?
+ * This could be a beginner topic, since it does not require advanced coding skills or proficiency in git internals, you still need to use git in general (so some technical skills are needed)
+ * This could be a great project for Hacktoberfest (we are actually looking for entry level oss contributions)
+ * Hacktoberfest accepts PRs as proof of work - does GitGitGadget count here? Otherwise Git doesn't use PRs
+ * There should be already notes to help how to do the translations
+* In the share out, someone pointed out that po/ uses a GitHub repo, so we don't need to worry about GGG - we can just try to get the po/ repo involved with Hacktoberfest
+
+Accessibility:
+
+* Are there any evaluation of accessibility for git? Is there any entity that is doing such assessment for OSS?
+ * Or are there any best practices? If there was such simple documentation (e.g. top 10 things you should look out for). Maybe using such a list would be important yet have a low entry threshold.
+* Could it be a beginner project (esp. non-code)? This could be perceived in a wrong way (in order to engage/use git, you have to make the project accessible by yourself).
+* Given there is no graphical UI, would it still be a UX problem? It seems to be.
+
+Summary:
+
+* Localizations could be a good non-technical starter projects for new contributors (they would still need some git user experience)
+ * This should include contributor documentation translation (++outreach)
+* Accessibility could be a good project for non-technical contributors (e.g. UX, UXR), but we should provide some starting material about non-GUI accessibility best practices (or essentially do some work on our own first)
+
+Next steps:
+
+1. Check whether we can use localization topics for GitGitGadget and Hacktoberfest
+2. Research accessibility documentation/processes for non-GUI tools, send a patch with best practices document/summary (or add to submitting patches style doc)
+
+Breakout #2
+
+**Attracting non-code contributions**
+
+Non-code Contributions are not as visible (on the mailinglist).
+
+Community spotlights could be highlighted on the git site, because those show a broad spectrum of contributions and contributors
+
+Social media account(s) for Git?
+
+**Code Review (Bias, upsetting reactions)**
+
+* To a non-contributor, it seems like patches don't get dropped often. To contributors, they're aware of many instances of patches sent to the list getting neglected.
+* Review feedback is often friendly but can be elitist.
+* Few active reviewers. How can we get more?
+* After you develop a big feature, you can feel responsible for providing review feedback for any future contributions in that area. Makes it harder to have time to continue to make new contributions.
+* Review feedback can be nitpicky.
+ * Don't want to lower the quality bar.
+ * Best practice is to review “top down”, starting with concepts, designs, architecture and then moving on to specific code or style issues.
+ * If you think those “top” areas are fine, say so in your feedback.
+ * Nitpicks are more frequent because they're less time consuming and simpler to approach for less experienced reviewers.
+* If you spend any significant time looking at a patch, let the maintainer know, even if you don't have specific feedback.
+* Hard to do good review without significant time investment
+ * The tools setup to apply patches from the list can be complicated (use mutt or you're out of luck?)
+ * Not always clear what patches are based on, might not apply cleanly if you don't try them soon after they're posted to the list
+ * Hard to keep track of threads on the list and what patches go together
+ * GGG has a commit for any patch sent to the list, so it's easy to get what someone else sends as a branch
+* Could try to use something like snowpatch to run CI on patches sent to the list
+ * Hard to make this work well all the time
+* Junio applies patches to topics and push them to his public repo
+ * Can run CI on those topics
+ * Topic names are picked by Junio and not trivially mappable
+ * What's the feedback loop for getting CI run info or topic name info back onto the list so the contributor knows it happened?
+ * Junio doesn't do this immediately and can wait longer for RFC patches
+ * Junio published Git notes (“amlog”) for a while to map Message-IDs to commits in git/git, but it was discontinued. GitGitGadget tries to reconstruct that mapping (“refs/notes/mail-to-commit” and “refs/notes/commit-to-mail”) but often fails to identify the mapping correctly
+* Positive feelings about Git's code review not being done in any particular Git hosting platform/service, but instead staying as agnostic as possible.
+* Review comments can be overly vague or overly concise and can appear rude.
+ * Regular contributors sending an email to the reviewer when they see this happen often produces positive results.
+ * Would be better to not have to do this.
+* Consider using more questions in review comments or other ways to come across as less formal.
+ * “Speak like a human”
+ * “Say your criticism in an inviting way”
+* There's a perception that some contributors get more nitpicking than others
+ * This can be especially bad for a new contributor that might end up discouraged from completing their contribution or making future contributions.
+* There's a challenge where a new big feature is sent to the list, but without a prior “proposal” or design discussion. Some negative (but hopefully constructive) feedback on the big feature is likely, especially for a new contributor, but even with an earlier “design review” the project wouldn't guarantee a smooth path forward.
+* When users send to the list “I wish Git did X”, often the response is “Sure! Send a patch”. This could come with more guidance to the user with how to send a patch for that feature.
+ * It takes time to research and write up that guidance (Dscho mentioned 2-4 hours on average).
+ * There's a chance this additional guidance would be wasted effort.
+ * Limiting the time investment with the initial reply is probably a good idea.
+ * Include a specific offer to help (if you are willing to give it), to avoid writing up detailed pointers that are then not picked up.
+* If a contributor is stuck, asking “What have you tried so far?” and perhaps a specific example “Did you look in <xyz file>?” can get them moving in the correct direction.
+* It'd be great to codify some best practices for reviewers
+ * Helps set expectations for contributors and provides guidelines for reviewers
+ * Should include:
+ * Read patches linearly, then write an overall review at the beginning of the series
+ * Don't just say what's wrong with the contribution
+ * Summarize overall thoughts of the series
+ * “Speak like a human”
+ * “Say your criticism in an inviting way”
+ * Invite the contributor to ask for more help
+ * Review “top down”, starting with concepts, designs, architecture and then moving on to specific code or style issues
+
+**User and contributor documentation**
+
+* supporting contributors and supporting users: Does git suffer from maintainer burnout? Does the project lack dedicated contributors? Are git's processes, tools, and documentation welcoming to contributors? How does the last question differ for end users?
+* Better 'documentation' about differing tones and style in mailing list discussions, and how to manage and inform about that.
+* Need to document the implicit code quality expectations and target system (Linux)?
+
+Discussion:
+
+* About mentoring discussion: **when people submit their first patch, they get confused on the messaging they get from the mailing list**
+ * there is a **common code/words lists** that is used by experienced contributors
+ * at the same time there can be even confusion among experienced contributors too
+ * Hence, having a set of agreed phrases people reply <- this would be for people interacting with the mailing list
+ * **A reviewer guide** would be a good way to go
+* Linux-like conventions can be implicit context that is hard to pick up
+ * Users may not be aware of conventions inherited from Linux => we need to explain to users why things needs to be done in a linux-like way (otherwise they would not be accepted)
+ * Git is solid software that was designed to support Linux development, yet it has grown out of that usage… hence better documentation for users and contributors is more important than it used to be.
+ * It is more about giving people understanding that they should not be put off at start => it may take some time before your contributions are accepted on first draft, yet we want you to know that you will get community support
+ * Given the importance and impact of Git (and being able to maintain/develop it forward, including backward compatibility criteria), we need to make sure that are aware of it and understand that sometimes needing to re-submitting a patch a few times is necessary
+* The hard part of all these discussions is deciding who is going to write this
+ * **Writing code on the git list is easy, writing documentation and submitting patches for the manuals is much harder** (also since it is heavily opinionated) - e.g. whether HEAD is detached "on" or "at"… hence even existing contributors have documentation patches that left hanging because reviewers could not understand it (as you fall into a pit once you try to understand it more)
+ * We have not engaged with Google Summer of Docs, we should be able to engage with prospective technical writers... but for this we need a good mentor for it, too
+* **We have introductory documentation, which is linked in other documents. We should refactor our documentation in the same way** (so there is only one explanation for a specific subject).
+ * Such sections could be dynamically interchanged depending on the level of details the user need to know
+* We tend to only have **reference manuals**, which are good as a reference, but to use these you already need to know what you want to do. At the moment the standard man page does not have a section “**let me help you learn this**”.
+* The user manual is not discoverable (`git help --guides` does not list the user manual), it should be easy to go to it from `git help`
+* What about a good presentation/article explaining it, in a sense that you can convey a lot with a good picture rather than lengthy documentation
+* We should be able to put good pictures/graphs in the documentation rather than just plain text (e.g. which way a given string of commits is executed)
+ * Key hurdle is that we don't have a good picture format that could be easily diffed/edited/reviewed, adding an extra commit to such graph should be simple to understand
+* A quick start guide (we could build on top of my first contribution), there are various reference documents that the contributor
+ * one example could be “how to send the email”, yet it refers to GitGitGadget (this still may be obscure for the new users, as we may just not think like the beginners)
+
+Next steps:
+1. Get Technical Writer help to check if our documents/explanations are understandable to the new users/contributors
+ 1. Maybe some Google Summer of Docs opportunities
+2. Agree upon a common code/word lists used in the mailing list
+3. Publish a reviewer guide
+ 1. how to look at the code, what to expect
+ 2. how do we tell the other person whether we agree/disagree with their patch and what they can do about it
+4. Publish an overview document of the complete process of contributing to git (e.g. on how interaction with the community work, what are you doing and what, what you should expect)
+ 1. Such document should include all the need-to-know information directly, links should only be added if there is extra background information
+ 2. my first contribution
+ 3. Have a technical writer to go through it
+5. Explain the context of why Git is important to open source development and what is the result of it (e.g. expect high standard == push back is common, yet you should expect)
+ 1. Also explain prioritization between users, use cases - we cannot compromise on core requirements
+ 2. This doc should be concise (half page max)
+6. Assess the need to refactor documentation and make single references for specific subjects instead of multiple instances
+7. Research potential graph/picture format that could be used in git documentation to make it more
+ 1. Key feature of such format should be easy way to review incremental patches to graphs/pictures via git mailing list
+
+Breakout #3
+
+**Name mapping without making deadnames more prominent**
+
+* places we're not using the mailmap yet
+ * particularly interested in signed tags
+ * what's the meaning of the signature when it is a remapped name?
+ * what is the usual practice with gpg? Reupload to keyserver?
+ * revoking an id doesn't remove it from the key, keyserver is always additive
+ * so if you want to avoid your deadname, need to make a new key
+ * wasn't able to get benefit from mailmap because every commit has name, deadname (signed-off-by)
+* but also: not wanting to put the deadname next to the real name
+ * can use a hash (SHA256)
+ * brian carlson will send a patch
+ * might make it hard to do cleanups, tradeoff may still be worth it
+ * how do you review such a patch?
+ * having to mention the deadname in the context of the review is painful
+ * can point to a commit instead, say here's an example of “git show <commit>” after this change
+ * have thought about that --- does it improve things?
+ * addresses the problem space slightly but not very
+ * there's an issue with someone's deadname coming up casually to a user that doesn't know or care
+ * that's basically already solved by the mailmap
+ * you don't have to look at the mailmap unless you want to add a mention
+ * on the other hand, it's trivial to find a finite list of things
+ * can obscure the "To" side (encrypt it using the deadname as a key)
+ * export restriction complexity?
+ * if someone wants to not be associated with their old identity at all, the only option is clean slate, two entirely separate histories
+ * if we were starting from scratch, could have an author token and a separate unversioned lookup mechanism
+ * people change their name for other reasons --- e.g. were in an abusive relationship associated with another name
+ * immutability
+ * hashing, public/private key magic as a way out?
+ * how useful is it to make it harder to accidentally run into a deadname?
+ * one thing that doesn't violate immutability is “all author information uses an opaque token” so everyone is in the mailmap
+ * is that something git.git would want to do?
+ * is that something we want to support other people doing?
+ * can put a no-op hash mailmap entries for everyone as first step
+ * trans visibility is great but it's better if it happens on your own terms
+ * .git/info/mailmap might be useful so the mapping doesn't even need to be version controlled
+ * sounds fussy, Peff is really happy Git doesn't require a CLA
+ * or could use a ref like refs/meta/mailmap, allowing garbage collection
+* action items
+ * trailers don't use mailmap, fix it (stolee adding to his backlog)
+ * hashed mailmap (bmc to send a patch or design proposal in the next few weeks)
+ * on-list discussion on improving usability of mailmap outside version control history
+ * "Is a project interested in buying into and experimenting with this mechanism?"
+
+**User Experience Research (UXR)**
+
+User (as opposed to: contributor) research on improvements in Git focused on inclusion / end users' needs and wants for inclusion.
+
+There was some interest in how language affects people:
+
+* `git blame` has negative connotation - `git annotate` alias announced on the mailing list, but `svn blame` was around for a long time, so people cling to blame for usability reasons, ease of use
+* blacklist / whitelist - blocklist / allowlist: has not been discussed on the mailing list so far.
+* master/main - naming of the default branch sparked discussion, which hasn't come to a conclusion yet
+
+Mercurial's UI is more opinionated than Git, freedom might stifle rather than help. Dscho is interested in seeing a person study this (as part as their PhD?)
+
+We make changes, based upon assumptions, but we fail to test whether those changes work for people. Christian mentioned that GitLab did such a study (for a web editor, though, not for the command-line experience) and was able to avoid going in the wrong direction.
+
+Improve the CLI experience, rather than look at GUIs. There are several mature GUIs out there.
+
+We should consolidate research that has been done so far, sharing out publicly as a starting point towards understanding UX.
+
+Albert mentioned there might be research available on Google's side.
+
+How do we learn about folks' experience with git?
+
+Are there events / moments where we speak to users?
+
+Maybe the Git Merge event, although very GitHub-heavy? Unfortunately this year's edition took place in COVID time so wasn't well-visited, and for some reasons talks weren't recorded.
+
+A second iteration of this event, open for end-users?
+
+At trainings? It's a difficult concept for new folks to wrap their head around, where Git is not linear.
+
+Studying the top-voted Git issues on stackoverflow?
+
+Existing getting started guides are dated, convoluted - they feel like Git still needs to be sold to people. There is “Everyday Git” in Git's own repository, and it has been around, like, forever.
+
+Possible to send out surveys via Git binary, collect analytics?
+
+Would be valuable to research why people use Git? Who would fund research?
+
+**Beginner level contributions (tech and non-tech)**
+
+* Educational content within existing documentation for end users
+ * It should be referenced from man pages too (a good example is matlab manual, also having some “magic” ready to go, learning repos, where you can try all the commands and learn from)
+ * Go did similar thing for code contributors, automating a'la “Hello Go” examples
+ * Even if it would take just a few lines to do it, we should it available it in just one line (to setup given starter repo and learn from it)
+ * Should include graphical documentation (simple enough to understand changes at the patch level)
+ * Maybe we can get some hints on what to explain better from “why I hate git” ;)
+ * Good ready-to-use examples explaining merkle tree mechanics in git
+* Is there an equivalent of a “git first contribution” tag/label, how these are triaged
+ * For bugs/features, git uses chromium bug tracker unofficially
+ * How does git community prioritize work? There is no master list/project
+ * Hashtag for work that is open to be done to everyone, but there is no way to distinct between complex and starter ones
+ * We could add such tag for starter opportunities
+* Is there documentation that explains how to filter through a mailing list?
+ * git community does not use any specific platform that would allow us to easily do such easy filtering/tagging - part of the reason is to be agnostic and do not favour any specific service/framework, yet this way we have a bit of anarchy-like way of working via mailing list
+* There is a high priority on core bits of git, hence we don't pay too much attention to smaller functionality (e.g. those that are meant to help beginner users => perhaps a better API long term)
+* What do we think about paying to contributors? Including this as a way to attract more contributors.
+ * It can be considered non-inclusive in a way - people may want to contribute, yet the financial aspect puts them away (GSoC, GSoD, Outreachy)
+ * It is not clear if current contributors are being paid for their git work.
+ * There is also a matter of becoming a contributor because you are paid to do this, or because you wanted to work on git.
+* We try to make new contributors more visible by interviewing them for Git Rev News (“Developer Spotlight”). Kaartic would appreciate suggestions.
+* We have no visibility why people don't succeed in making a contribution. Could we ask publicly who wasn't able to contribute, in a self-deprecating way, turning it more into a fun thing?
+* There is no good way to pass on ongoing work - in a sense of giving an opportunity to either take it forward by someone else or asking for someone to help (e.g. I gone so far and won't have time or need someone to help with the documentation)
+* Discussed “My first patch submission” at Go project - not many people stick, but it is a stable stream of new people
+ * This would require a few core people to drive such cohorts - high intensive/high investment, yet it yields 5-8% retention rate. Naturally, people who came to the program had to invest their time too.
+ * Maybe the git community should have a contributor week/day (“hackathon”)… after that we could put some of the volunteers on a mentoring path?
+* Numbers on how many of the core contributors are paid to work on Git. - Survey?
