{"thread":{"id":"51883","subject":"[DISCUSSION] Growing the Git community","startedAt":"2019-09-19T16:30:18Z","lastAt":"2019-11-15T04:48:35Z","messageCount":45,"participants":["Derrick Stolee","Denton Liu","Klaus Sembritzki","Emily Shaffer","Mike Hommey","Jeff King","Elijah Newren","Philip Oakley","brian m. carlson","Randall S. Becker","Garima Singh","Junio C Hamano","Johannes Schindelin","Pierre Tardy","Jakub Narebski","Christian Couder","Thomas Gummerer","Pratyush Yadav"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"382595","messageId":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","threadId":"51883","inReplyTo":null,"subject":"[DISCUSSION] Growing the Git community","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-09-19T16:30:13Z","receivedAt":"2019-09-19T16:30:18Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n\"Inclusion & Diversity\". We discussed ideas for how to make the community\nmore welcoming to new contributors of all kinds. Let's discuss some of\nthe ideas we talked about, and some that have been growing since.\n\nFeel free to pick apart all of the claims I make below. This is based\non my own experience and opinions. It should be a good baseline\nfor us to all arrive with valuable action items.\n\nI have CC'd some of the people who were part of that discussion. Sorry\nif I accidentally left someone out.\n\nI. Goals and Perceived Problems\n\nAs a community, our number one goal is for Git to continue to be the best\ndistributed version control system. At minimum, it should continue to be\nthe most widely-used DVCS. Towards that goal, we need to make sure Git is\nthe best solution for every kind of developer in every industry. The\ncommunity cannot do this without including developers of all kinds. This\nmeans having a diverse community, for all senses of the word: Diverse in\nphysical location, gender, professional status, age, and others.\n\nIn addition, the community must continue to grow, but members leave the\ncommunity on a regular basis for multiple reasons. New contributors must\njoin and mature within the community or the community will dwindle. Without\ndedicating effort and attention to this, natural forces may result in the\ncommunity being represented only by contributors working at large tech\ncompanies focused on the engineering systems of very large groups.\n\nIt is worth noting that this community growth must never be at the cost\nof code quality. We must continue to hold all contributors to a high\nstandard so Git stays a stable product.\n\nHere are some problems that may exist within the Git community and may\nform a barrier to new contributors entering:\n\n1. Discovering how to contribute to Git is non-obvious.\n\n2. Submitting to a mailing list is a new experience for most developers.\n   This includes the full review and discussion process.\n\n3. The high standards for patch quality are intimidating to new contributors.\n\n4. Some people do not feel comfortable engaging in a community without\n   a clear Code of Conduct. This discomfort is significant and based on real\n   experiences throughout society.\n\n5. Since Git development happens in a different place than where users\n    acquire the end product, some are not aware that they can contribute.\n\nII. Approach\n\nThe action items below match the problems listed above.\n\n1. Improve the documentation for contributing to Git.\n\nIn preparation for this email, I talked to someone familiar with issues\naround new contributors, and they sat down to try and figure out how to\ncontribute to Git. The first place they went was https://github.com/git/git\nand looked at the README. It takes deep reading of a paragraph to see a\nlink to the SubmittingPatches docs.\n\nTo improve this experience, we could rewrite the README to have clearer\nsection markers, including one \"Contributing to Git\" section relatively\nhigh in the doc. We may want to update the README for multiple reasons.\nIt should link to the new \"My First Contribution\" document\n(https://git-scm.com/docs/MyFirstContribution).\n\n2. Add more pointers to GitGitGadget\n\nWe have a reference to GitGitGadget in the GitHub PR template to try and\nget people who try to submit a pull request to git/git to instead create\none on GitGitGadget. However, that captures contributors who didn't read\nthe docs about how to submit! (This is somewhat covered by the \"My First\nContribution\" doc as well, so making that more visible will also help.)\n\nCould we reference GitGitGadget as part of the Submitting Patches doc\nas well?\n\n3. Introduce a new \"mentors\" mailing list\n\nFrom personal experience, all new contributors at Microsoft (after Jeff\nHostetler at least) have first had their patches reviewed privately by\nthe team before sending them upstream. Each time, the new contributor\ngained confidence about the code and had help interpreting feedback from\nthe list.\n\nWe want to make this kind of experience part of the open Git community.\n\nThe idea discussed in the virtual summit was to create a new mailing\nlist (probably a Google group) of Git community members. The point of\nthe list is for a new contributor to safely say \"I'm looking for a\nmentor!\" and the list can help pair them with a mentor. This must\ninclude (a) who is available now? and (b) what area of the code are they\nhoping to change?\n\nAs evidence that this is a good idea, please see the recent research\npaper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\nImproves Engagement in Social Q&A Communities\" [1].\n\n[1] http://www.chrisparnin.me/pdf/chi18.pdf\n\nWhen asking your first question on Stack Overflow, this group added\na pop-up saying \"Would you like someone to help you with this?\". Then,\na mentor would assist crafting the best possible question to ensure\nthe asker got the best response possible.\n\nI believe this would work in our community, too. The action items\nare:\n\na. Create the mailing list and add people to the list.\n\nb. Add a pointer to the list in our documentation.\n\nNote: the people on the mentoring list do not need to be\n\"senior\" community members. In fact, someone who more recently\njoined the community has a more fresh perspective on the process.\n\n4. Add an official Code of Conduct\n\nSo far, the community has had an unofficial policy of \"be nice,\nas much as possible\". We should add a Code of Conduct that is\nmore explicit about the behavior we want to model. This was also\ndiscussed in the meeting with wide approval.\n\n5. Advertise that Git wants new contributors\n\nAfter we put items 1-4 in place, we should reach out to the\ngeneral tech community that we are interested in new\ncontributors. It's not enough to open the door, we should\npoint people to it.\n\nThis item is much less explicit about the _how_. This could\nbe done at the individual level: posting to social media or\nblog posts. But perhaps there is something more official we\ncould do?\n\nIII. Measurement\n\nHow do we know if any of these items make a difference? We\nneed to gather data and measure the effects. With the size\nof our community, I expect that it will take multiple years\nto really see a measurable difference. But, no time like\nthe present to ask \"What does success look like?\"\n\nHere are a few measurements that we could use. Each \"count\"\ncould be measured over any time frame. We could use major\nreleases as time buckets: v2.22.0 to v2.23.0, for example.\n\n1. How many first-time contributors sent a patch?\n\n2. How many contributors had their first commit accepted into\n   the release?\n\n3. How many contributors started reviewing?\n\n4. How many total patches/reviews did the list receive?\n\nWhat other measurements would be reasonable? We could try\nbuilding tools to collect these measurements for the past\nto see historical trends. Based on that data, we may be\nable to set goals for the future.\n\nWith such a small community, and an expected small number\nof new contributors, it may also be good to do interviews\nwith the new contributors to ask about their experience.\nIn particular, we would be looking for moments where they\nhad trouble or experience friction. Each of those\nmoments is a barrier that others may not be clearing.\n\n\nI look forward to the discussion.\n\nThanks,\n-Stolee\n"},{"id":"382596","messageId":"20190919173423.GA70421@dentonliu-ltm.internal.salesforce.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-09-19T17:34:23Z","receivedAt":"2019-09-19T17:34:29Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hello,\n\nAs a relatively new contributor (just less than a year), I guess I'll\nshare some thoughts:\n\nOn Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n> \n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n> \n> I have CC'd some of the people who were part of that discussion. Sorry\n> if I accidentally left someone out.\n> \n> I. Goals and Perceived Problems\n> \n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system. At minimum, it should continue to be\n> the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry. The\n> community cannot do this without including developers of all kinds. This\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n> \n> In addition, the community must continue to grow, but members leave the\n> community on a regular basis for multiple reasons. New contributors must\n> join and mature within the community or the community will dwindle. Without\n> dedicating effort and attention to this, natural forces may result in the\n> community being represented only by contributors working at large tech\n> companies focused on the engineering systems of very large groups.\n\nFrom my anecdotal experience in trying to get my developer friends to\ncontribute, they've told me that it isn't really that much fun for them\nto contribute to free software. After doing one day job, they said they\ndidn't really want to come home to do another one.\n\nI guess one thing we should consider is \"how do we make it more fun to\ncontribute to Git?\" Not sure if that's a naïve goal but I feel like it\nwould help to keep people coming back.\n\n> \n> It is worth noting that this community growth must never be at the cost\n> of code quality. We must continue to hold all contributors to a high\n> standard so Git stays a stable product.\n> \n> Here are some problems that may exist within the Git community and may\n> form a barrier to new contributors entering:\n> \n> 1. Discovering how to contribute to Git is non-obvious.\n> \n> 2. Submitting to a mailing list is a new experience for most developers.\n>    This includes the full review and discussion process.\n> \n> 3. The high standards for patch quality are intimidating to new contributors.\n> \n> 4. Some people do not feel comfortable engaging in a community without\n>    a clear Code of Conduct. This discomfort is significant and based on real\n>    experiences throughout society.\n> \n> 5. Since Git development happens in a different place than where users\n>     acquire the end product, some are not aware that they can contribute.\n> \n> II. Approach\n> \n> The action items below match the problems listed above.\n> \n> 1. Improve the documentation for contributing to Git.\n> \n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n\nAside from getting the first email sent, most of my time learning to\ncontribute to Git stemmed from the fact that there's a lot of tribal\nknowledge that's not really written down anywhere. Here are some of the\nsmaller things that confused me:\n\nI remember some other docs I read included howto/maintain-git.txt about\na month in. I remember feeling confused about what Junio was doing with\nall of the integration branches so reading this really cleared things up\nfor me.\n\nOn that topic, I didn't realise the gitster/git repo existed for a while\nso, from my pespective, my patches went into a black hole and then\nsomehow magically got incorporated into Git.\n\nActually, one thing that I'm still confused about is what people do with\ntheir topic branches. I learned a long time ago not to rebase onto\nmaster (hence why I introduced rebase --keep-base) but aside from that,\nare we supposed to pull down the topic branches and edit from there or\nkeep working on top of a local branch? I think it might be help if\nsomeone experienced in the community wrote a howto/contribute-to-git.txt\nand just spent a while talking about their workflow in detail.\n\n> \n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n\nI agree, this would've been really helped me get started if it were\naround a year ago.\n\n> \n> 2. Add more pointers to GitGitGadget\n> \n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n> \n> Could we reference GitGitGadget as part of the Submitting Patches doc\n> as well?\n> \n> 3. Introduce a new \"mentors\" mailing list\n> \n> >From personal experience, all new contributors at Microsoft (after Jeff\n> Hostetler at least) have first had their patches reviewed privately by\n> the team before sending them upstream. Each time, the new contributor\n> gained confidence about the code and had help interpreting feedback from\n> the list.\n> \n> We want to make this kind of experience part of the open Git community.\n> \n> The idea discussed in the virtual summit was to create a new mailing\n> list (probably a Google group) of Git community members. The point of\n> the list is for a new contributor to safely say \"I'm looking for a\n> mentor!\" and the list can help pair them with a mentor. This must\n> include (a) who is available now? and (b) what area of the code are they\n> hoping to change?\n> \n> As evidence that this is a good idea, please see the recent research\n> paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> Improves Engagement in Social Q&A Communities\" [1].\n> \n> [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> \n> When asking your first question on Stack Overflow, this group added\n> a pop-up saying \"Would you like someone to help you with this?\". Then,\n> a mentor would assist crafting the best possible question to ensure\n> the asker got the best response possible.\n> \n> I believe this would work in our community, too. The action items\n> are:\n> \n> a. Create the mailing list and add people to the list.\n> \n> b. Add a pointer to the list in our documentation.\n> \n> Note: the people on the mentoring list do not need to be\n> \"senior\" community members. In fact, someone who more recently\n> joined the community has a more fresh perspective on the process.\n\nAnother discouraging thing when I was just starting out was sending a\nout a patch and just getting radio silence (especially the first one, I\nwasn't sure if it even sent out properly!). Perhaps in the main list, we\ncould get people to tag with [FIRST PATCH] or something when sending in\ntheir first patch.\n\nIf the patch is not desired, then we should explain why it wasn't\ndesired instead of just leaving them hanging. I know Junio is too busy\nto say \"hey, I'm picking this patch up\" to every single patchset, but if\na patch is desired, perhaps the rest of us could pick up the slack and\nsay, \"hey, your patchset was picked up by Junio in his gitster repo on\nthis branch\".\n\n> \n> 4. Add an official Code of Conduct\n> \n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n\nFrom what I've personally read and experienced, I don't think that an\nofficial Code of Conduct is really warranted. Everyone I've interacted\nwith has been really kind. Perhaps a new contributor might interpret the\ncurtness of replies here as someone being rude but I quickly learned\nthat it's more out of necessity since everyone is busy.\n\nFrom reading the mailing list archives, I know that in the past, there\nhave been some flamewars and some abrasive individuals but I think\nthat's a problem of the past.\n\nI also see some drawbacks to implementing a CoC as well. First of all,\nit just feels like unnecessary bureaucracy. Second, I think it'll\nprobably cause a stir like it did when the Linux kernel introduced it.\nOf course, all that noise will die down eventually but I feel like it'll\nbring the wrong kind of attention to Git.\n\n(Then again, maybe it'll attract more contributors in the process, who\nknows.)\n\n> \n> 5. Advertise that Git wants new contributors\n> \n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n> \n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n> \n> III. Measurement\n> \n> How do we know if any of these items make a difference? We\n> need to gather data and measure the effects. With the size\n> of our community, I expect that it will take multiple years\n> to really see a measurable difference. But, no time like\n> the present to ask \"What does success look like?\"\n> \n> Here are a few measurements that we could use. Each \"count\"\n> could be measured over any time frame. We could use major\n> releases as time buckets: v2.22.0 to v2.23.0, for example.\n> \n> 1. How many first-time contributors sent a patch?\n> \n> 2. How many contributors had their first commit accepted into\n>    the release?\n> \n> 3. How many contributors started reviewing?\n> \n> 4. How many total patches/reviews did the list receive?\n> \n> What other measurements would be reasonable? We could try\n> building tools to collect these measurements for the past\n> to see historical trends. Based on that data, we may be\n> able to set goals for the future.\n> \n> With such a small community, and an expected small number\n> of new contributors, it may also be good to do interviews\n> with the new contributors to ask about their experience.\n> In particular, we would be looking for moments where they\n> had trouble or experience friction. Each of those\n> moments is a barrier that others may not be clearing.\n\nI've dropped some of my experiences here but I'd be open to do an\ninterview if needed.\n\n> \n> \n> I look forward to the discussion.\n\nThanks for starting the discussion,\n\nDenton\n> \n> Thanks,\n> -Stolee\n"},{"id":"382601","messageId":"CADMnYXCGsTSuxiZuKtz5FZmjthkcwz=k8+m=4_=AU9t0BRERug@mail.gmail.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-19T18:44:46Z","receivedAt":"2019-09-19T18:45:02Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"Hello all,\n\n1. Long texts stem from false (You can deduce anything from something\nthat is wrong).\n2. TL;DR is therefore sane.\n3. (Inclusion & Diversity) is a tautology, it includes all of it.\n\nCheers,\nKlaus Sembritzki\n\n\nOn Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n>\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n>\n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n>\n> I have CC'd some of the people who were part of that discussion. Sorry\n> if I accidentally left someone out.\n>\n> I. Goals and Perceived Problems\n>\n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system. At minimum, it should continue to be\n> the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry. The\n> community cannot do this without including developers of all kinds. This\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n>\n> In addition, the community must continue to grow, but members leave the\n> community on a regular basis for multiple reasons. New contributors must\n> join and mature within the community or the community will dwindle. Without\n> dedicating effort and attention to this, natural forces may result in the\n> community being represented only by contributors working at large tech\n> companies focused on the engineering systems of very large groups.\n>\n> It is worth noting that this community growth must never be at the cost\n> of code quality. We must continue to hold all contributors to a high\n> standard so Git stays a stable product.\n>\n> Here are some problems that may exist within the Git community and may\n> form a barrier to new contributors entering:\n>\n> 1. Discovering how to contribute to Git is non-obvious.\n>\n> 2. Submitting to a mailing list is a new experience for most developers.\n>    This includes the full review and discussion process.\n>\n> 3. The high standards for patch quality are intimidating to new contributors.\n>\n> 4. Some people do not feel comfortable engaging in a community without\n>    a clear Code of Conduct. This discomfort is significant and based on real\n>    experiences throughout society.\n>\n> 5. Since Git development happens in a different place than where users\n>     acquire the end product, some are not aware that they can contribute.\n>\n> II. Approach\n>\n> The action items below match the problems listed above.\n>\n> 1. Improve the documentation for contributing to Git.\n>\n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n>\n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n>\n> 2. Add more pointers to GitGitGadget\n>\n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n>\n> Could we reference GitGitGadget as part of the Submitting Patches doc\n> as well?\n>\n> 3. Introduce a new \"mentors\" mailing list\n>\n> From personal experience, all new contributors at Microsoft (after Jeff\n> Hostetler at least) have first had their patches reviewed privately by\n> the team before sending them upstream. Each time, the new contributor\n> gained confidence about the code and had help interpreting feedback from\n> the list.\n>\n> We want to make this kind of experience part of the open Git community.\n>\n> The idea discussed in the virtual summit was to create a new mailing\n> list (probably a Google group) of Git community members. The point of\n> the list is for a new contributor to safely say \"I'm looking for a\n> mentor!\" and the list can help pair them with a mentor. This must\n> include (a) who is available now? and (b) what area of the code are they\n> hoping to change?\n>\n> As evidence that this is a good idea, please see the recent research\n> paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> Improves Engagement in Social Q&A Communities\" [1].\n>\n> [1] http://www.chrisparnin.me/pdf/chi18.pdf\n>\n> When asking your first question on Stack Overflow, this group added\n> a pop-up saying \"Would you like someone to help you with this?\". Then,\n> a mentor would assist crafting the best possible question to ensure\n> the asker got the best response possible.\n>\n> I believe this would work in our community, too. The action items\n> are:\n>\n> a. Create the mailing list and add people to the list.\n>\n> b. Add a pointer to the list in our documentation.\n>\n> Note: the people on the mentoring list do not need to be\n> \"senior\" community members. In fact, someone who more recently\n> joined the community has a more fresh perspective on the process.\n>\n> 4. Add an official Code of Conduct\n>\n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n>\n> 5. Advertise that Git wants new contributors\n>\n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n>\n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n>\n> III. Measurement\n>\n> How do we know if any of these items make a difference? We\n> need to gather data and measure the effects. With the size\n> of our community, I expect that it will take multiple years\n> to really see a measurable difference. But, no time like\n> the present to ask \"What does success look like?\"\n>\n> Here are a few measurements that we could use. Each \"count\"\n> could be measured over any time frame. We could use major\n> releases as time buckets: v2.22.0 to v2.23.0, for example.\n>\n> 1. How many first-time contributors sent a patch?\n>\n> 2. How many contributors had their first commit accepted into\n>    the release?\n>\n> 3. How many contributors started reviewing?\n>\n> 4. How many total patches/reviews did the list receive?\n>\n> What other measurements would be reasonable? We could try\n> building tools to collect these measurements for the past\n> to see historical trends. Based on that data, we may be\n> able to set goals for the future.\n>\n> With such a small community, and an expected small number\n> of new contributors, it may also be good to do interviews\n> with the new contributors to ask about their experience.\n> In particular, we would be looking for moments where they\n> had trouble or experience friction. Each of those\n> moments is a barrier that others may not be clearing.\n>\n>\n> I look forward to the discussion.\n>\n> Thanks,\n> -Stolee\n"},{"id":"382606","messageId":"CADMnYXCdEMQ9BEq+DdByDTteZmC3j+c8WuHVx3T9Cb1QNu8zaw@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXCGsTSuxiZuKtz5FZmjthkcwz=k8+m=4_=AU9t0BRERug@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-19T19:12:09Z","receivedAt":"2019-09-19T19:12:25Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"Hello all,\n\nA game-theoretical insight, as the GIT mailing-list has just been\nhacked: Such a move necessitates everyone to down-value the hackers'\nintellects, if it was not a false-flag-operation.\n\nCheers,\nKlaus Sembritzki\n\n\nOn Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> Hello all,\n>\n> 1. Long texts stem from false (You can deduce anything from something\n> that is wrong).\n> 2. TL;DR is therefore sane.\n> 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n>\n> Cheers,\n> Klaus Sembritzki\n>\n>\n> On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> >\n> > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > more welcoming to new contributors of all kinds. Let's discuss some of\n> > the ideas we talked about, and some that have been growing since.\n> >\n> > Feel free to pick apart all of the claims I make below. This is based\n> > on my own experience and opinions. It should be a good baseline\n> > for us to all arrive with valuable action items.\n> >\n> > I have CC'd some of the people who were part of that discussion. Sorry\n> > if I accidentally left someone out.\n> >\n> > I. Goals and Perceived Problems\n> >\n> > As a community, our number one goal is for Git to continue to be the best\n> > distributed version control system. At minimum, it should continue to be\n> > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > the best solution for every kind of developer in every industry. The\n> > community cannot do this without including developers of all kinds. This\n> > means having a diverse community, for all senses of the word: Diverse in\n> > physical location, gender, professional status, age, and others.\n> >\n> > In addition, the community must continue to grow, but members leave the\n> > community on a regular basis for multiple reasons. New contributors must\n> > join and mature within the community or the community will dwindle. Without\n> > dedicating effort and attention to this, natural forces may result in the\n> > community being represented only by contributors working at large tech\n> > companies focused on the engineering systems of very large groups.\n> >\n> > It is worth noting that this community growth must never be at the cost\n> > of code quality. We must continue to hold all contributors to a high\n> > standard so Git stays a stable product.\n> >\n> > Here are some problems that may exist within the Git community and may\n> > form a barrier to new contributors entering:\n> >\n> > 1. Discovering how to contribute to Git is non-obvious.\n> >\n> > 2. Submitting to a mailing list is a new experience for most developers.\n> >    This includes the full review and discussion process.\n> >\n> > 3. The high standards for patch quality are intimidating to new contributors.\n> >\n> > 4. Some people do not feel comfortable engaging in a community without\n> >    a clear Code of Conduct. This discomfort is significant and based on real\n> >    experiences throughout society.\n> >\n> > 5. Since Git development happens in a different place than where users\n> >     acquire the end product, some are not aware that they can contribute.\n> >\n> > II. Approach\n> >\n> > The action items below match the problems listed above.\n> >\n> > 1. Improve the documentation for contributing to Git.\n> >\n> > In preparation for this email, I talked to someone familiar with issues\n> > around new contributors, and they sat down to try and figure out how to\n> > contribute to Git. The first place they went was https://github.com/git/git\n> > and looked at the README. It takes deep reading of a paragraph to see a\n> > link to the SubmittingPatches docs.\n> >\n> > To improve this experience, we could rewrite the README to have clearer\n> > section markers, including one \"Contributing to Git\" section relatively\n> > high in the doc. We may want to update the README for multiple reasons.\n> > It should link to the new \"My First Contribution\" document\n> > (https://git-scm.com/docs/MyFirstContribution).\n> >\n> > 2. Add more pointers to GitGitGadget\n> >\n> > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > get people who try to submit a pull request to git/git to instead create\n> > one on GitGitGadget. However, that captures contributors who didn't read\n> > the docs about how to submit! (This is somewhat covered by the \"My First\n> > Contribution\" doc as well, so making that more visible will also help.)\n> >\n> > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > as well?\n> >\n> > 3. Introduce a new \"mentors\" mailing list\n> >\n> > From personal experience, all new contributors at Microsoft (after Jeff\n> > Hostetler at least) have first had their patches reviewed privately by\n> > the team before sending them upstream. Each time, the new contributor\n> > gained confidence about the code and had help interpreting feedback from\n> > the list.\n> >\n> > We want to make this kind of experience part of the open Git community.\n> >\n> > The idea discussed in the virtual summit was to create a new mailing\n> > list (probably a Google group) of Git community members. The point of\n> > the list is for a new contributor to safely say \"I'm looking for a\n> > mentor!\" and the list can help pair them with a mentor. This must\n> > include (a) who is available now? and (b) what area of the code are they\n> > hoping to change?\n> >\n> > As evidence that this is a good idea, please see the recent research\n> > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > Improves Engagement in Social Q&A Communities\" [1].\n> >\n> > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> >\n> > When asking your first question on Stack Overflow, this group added\n> > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > a mentor would assist crafting the best possible question to ensure\n> > the asker got the best response possible.\n> >\n> > I believe this would work in our community, too. The action items\n> > are:\n> >\n> > a. Create the mailing list and add people to the list.\n> >\n> > b. Add a pointer to the list in our documentation.\n> >\n> > Note: the people on the mentoring list do not need to be\n> > \"senior\" community members. In fact, someone who more recently\n> > joined the community has a more fresh perspective on the process.\n> >\n> > 4. Add an official Code of Conduct\n> >\n> > So far, the community has had an unofficial policy of \"be nice,\n> > as much as possible\". We should add a Code of Conduct that is\n> > more explicit about the behavior we want to model. This was also\n> > discussed in the meeting with wide approval.\n> >\n> > 5. Advertise that Git wants new contributors\n> >\n> > After we put items 1-4 in place, we should reach out to the\n> > general tech community that we are interested in new\n> > contributors. It's not enough to open the door, we should\n> > point people to it.\n> >\n> > This item is much less explicit about the _how_. This could\n> > be done at the individual level: posting to social media or\n> > blog posts. But perhaps there is something more official we\n> > could do?\n> >\n> > III. Measurement\n> >\n> > How do we know if any of these items make a difference? We\n> > need to gather data and measure the effects. With the size\n> > of our community, I expect that it will take multiple years\n> > to really see a measurable difference. But, no time like\n> > the present to ask \"What does success look like?\"\n> >\n> > Here are a few measurements that we could use. Each \"count\"\n> > could be measured over any time frame. We could use major\n> > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> >\n> > 1. How many first-time contributors sent a patch?\n> >\n> > 2. How many contributors had their first commit accepted into\n> >    the release?\n> >\n> > 3. How many contributors started reviewing?\n> >\n> > 4. How many total patches/reviews did the list receive?\n> >\n> > What other measurements would be reasonable? We could try\n> > building tools to collect these measurements for the past\n> > to see historical trends. Based on that data, we may be\n> > able to set goals for the future.\n> >\n> > With such a small community, and an expected small number\n> > of new contributors, it may also be good to do interviews\n> > with the new contributors to ask about their experience.\n> > In particular, we would be looking for moments where they\n> > had trouble or experience friction. Each of those\n> > moments is a barrier that others may not be clearing.\n> >\n> >\n> > I look forward to the discussion.\n> >\n> > Thanks,\n> > -Stolee\n"},{"id":"382608","messageId":"CADMnYXBxXAYKANZaCQcvsRMQ6FrMPUSGqjKPFxhHFx3yj81k0A@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXCdEMQ9BEq+DdByDTteZmC3j+c8WuHVx3T9Cb1QNu8zaw@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-19T20:20:56Z","receivedAt":"2019-09-19T20:21:11Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"I hereby instruct the German military to kill our harrassers.\n\nOn Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> Hello all,\n>\n> A game-theoretical insight, as the GIT mailing-list has just been\n> hacked: Such a move necessitates everyone to down-value the hackers'\n> intellects, if it was not a false-flag-operation.\n>\n> Cheers,\n> Klaus Sembritzki\n>\n>\n> On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > Hello all,\n> >\n> > 1. Long texts stem from false (You can deduce anything from something\n> > that is wrong).\n> > 2. TL;DR is therefore sane.\n> > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> >\n> > Cheers,\n> > Klaus Sembritzki\n> >\n> >\n> > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > >\n> > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > the ideas we talked about, and some that have been growing since.\n> > >\n> > > Feel free to pick apart all of the claims I make below. This is based\n> > > on my own experience and opinions. It should be a good baseline\n> > > for us to all arrive with valuable action items.\n> > >\n> > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > if I accidentally left someone out.\n> > >\n> > > I. Goals and Perceived Problems\n> > >\n> > > As a community, our number one goal is for Git to continue to be the best\n> > > distributed version control system. At minimum, it should continue to be\n> > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > the best solution for every kind of developer in every industry. The\n> > > community cannot do this without including developers of all kinds. This\n> > > means having a diverse community, for all senses of the word: Diverse in\n> > > physical location, gender, professional status, age, and others.\n> > >\n> > > In addition, the community must continue to grow, but members leave the\n> > > community on a regular basis for multiple reasons. New contributors must\n> > > join and mature within the community or the community will dwindle. Without\n> > > dedicating effort and attention to this, natural forces may result in the\n> > > community being represented only by contributors working at large tech\n> > > companies focused on the engineering systems of very large groups.\n> > >\n> > > It is worth noting that this community growth must never be at the cost\n> > > of code quality. We must continue to hold all contributors to a high\n> > > standard so Git stays a stable product.\n> > >\n> > > Here are some problems that may exist within the Git community and may\n> > > form a barrier to new contributors entering:\n> > >\n> > > 1. Discovering how to contribute to Git is non-obvious.\n> > >\n> > > 2. Submitting to a mailing list is a new experience for most developers.\n> > >    This includes the full review and discussion process.\n> > >\n> > > 3. The high standards for patch quality are intimidating to new contributors.\n> > >\n> > > 4. Some people do not feel comfortable engaging in a community without\n> > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > >    experiences throughout society.\n> > >\n> > > 5. Since Git development happens in a different place than where users\n> > >     acquire the end product, some are not aware that they can contribute.\n> > >\n> > > II. Approach\n> > >\n> > > The action items below match the problems listed above.\n> > >\n> > > 1. Improve the documentation for contributing to Git.\n> > >\n> > > In preparation for this email, I talked to someone familiar with issues\n> > > around new contributors, and they sat down to try and figure out how to\n> > > contribute to Git. The first place they went was https://github.com/git/git\n> > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > link to the SubmittingPatches docs.\n> > >\n> > > To improve this experience, we could rewrite the README to have clearer\n> > > section markers, including one \"Contributing to Git\" section relatively\n> > > high in the doc. We may want to update the README for multiple reasons.\n> > > It should link to the new \"My First Contribution\" document\n> > > (https://git-scm.com/docs/MyFirstContribution).\n> > >\n> > > 2. Add more pointers to GitGitGadget\n> > >\n> > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > get people who try to submit a pull request to git/git to instead create\n> > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > Contribution\" doc as well, so making that more visible will also help.)\n> > >\n> > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > as well?\n> > >\n> > > 3. Introduce a new \"mentors\" mailing list\n> > >\n> > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > Hostetler at least) have first had their patches reviewed privately by\n> > > the team before sending them upstream. Each time, the new contributor\n> > > gained confidence about the code and had help interpreting feedback from\n> > > the list.\n> > >\n> > > We want to make this kind of experience part of the open Git community.\n> > >\n> > > The idea discussed in the virtual summit was to create a new mailing\n> > > list (probably a Google group) of Git community members. The point of\n> > > the list is for a new contributor to safely say \"I'm looking for a\n> > > mentor!\" and the list can help pair them with a mentor. This must\n> > > include (a) who is available now? and (b) what area of the code are they\n> > > hoping to change?\n> > >\n> > > As evidence that this is a good idea, please see the recent research\n> > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > Improves Engagement in Social Q&A Communities\" [1].\n> > >\n> > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > >\n> > > When asking your first question on Stack Overflow, this group added\n> > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > a mentor would assist crafting the best possible question to ensure\n> > > the asker got the best response possible.\n> > >\n> > > I believe this would work in our community, too. The action items\n> > > are:\n> > >\n> > > a. Create the mailing list and add people to the list.\n> > >\n> > > b. Add a pointer to the list in our documentation.\n> > >\n> > > Note: the people on the mentoring list do not need to be\n> > > \"senior\" community members. In fact, someone who more recently\n> > > joined the community has a more fresh perspective on the process.\n> > >\n> > > 4. Add an official Code of Conduct\n> > >\n> > > So far, the community has had an unofficial policy of \"be nice,\n> > > as much as possible\". We should add a Code of Conduct that is\n> > > more explicit about the behavior we want to model. This was also\n> > > discussed in the meeting with wide approval.\n> > >\n> > > 5. Advertise that Git wants new contributors\n> > >\n> > > After we put items 1-4 in place, we should reach out to the\n> > > general tech community that we are interested in new\n> > > contributors. It's not enough to open the door, we should\n> > > point people to it.\n> > >\n> > > This item is much less explicit about the _how_. This could\n> > > be done at the individual level: posting to social media or\n> > > blog posts. But perhaps there is something more official we\n> > > could do?\n> > >\n> > > III. Measurement\n> > >\n> > > How do we know if any of these items make a difference? We\n> > > need to gather data and measure the effects. With the size\n> > > of our community, I expect that it will take multiple years\n> > > to really see a measurable difference. But, no time like\n> > > the present to ask \"What does success look like?\"\n> > >\n> > > Here are a few measurements that we could use. Each \"count\"\n> > > could be measured over any time frame. We could use major\n> > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > >\n> > > 1. How many first-time contributors sent a patch?\n> > >\n> > > 2. How many contributors had their first commit accepted into\n> > >    the release?\n> > >\n> > > 3. How many contributors started reviewing?\n> > >\n> > > 4. How many total patches/reviews did the list receive?\n> > >\n> > > What other measurements would be reasonable? We could try\n> > > building tools to collect these measurements for the past\n> > > to see historical trends. Based on that data, we may be\n> > > able to set goals for the future.\n> > >\n> > > With such a small community, and an expected small number\n> > > of new contributors, it may also be good to do interviews\n> > > with the new contributors to ask about their experience.\n> > > In particular, we would be looking for moments where they\n> > > had trouble or experience friction. Each of those\n> > > moments is a barrier that others may not be clearing.\n> > >\n> > >\n> > > I look forward to the discussion.\n> > >\n> > > Thanks,\n> > > -Stolee\n"},{"id":"382609","messageId":"20190919204321.GA116396@google.com","threadId":"51883","inReplyTo":"20190919173423.GA70421@dentonliu-ltm.internal.salesforce.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-09-19T20:43:21Z","receivedAt":"2019-09-19T20:43:29Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:\n> Aside from getting the first email sent, most of my time learning to\n> contribute to Git stemmed from the fact that there's a lot of tribal\n> knowledge that's not really written down anywhere. Here are some of the\n> smaller things that confused me:\n\n+1 to unwritten knowledge. I learned quite a lot from comments on my\nearly reviews about utilities and patterns which I had no idea existed.\nI'd love to see more and better-organized documentation in Git project\n(in fact, that's one of my goals for this year - a contributor's manual,\nwhich was one of the topics discussed at the virtual summit).\n\n> Another discouraging thing when I was just starting out was sending a\n> out a patch and just getting radio silence (especially the first one, I\n> wasn't sure if it even sent out properly!). Perhaps in the main list, we\n> could get people to tag with [FIRST PATCH] or something when sending in\n> their first patch.\n> \n> If the patch is not desired, then we should explain why it wasn't\n> desired instead of just leaving them hanging. I know Junio is too busy\n> to say \"hey, I'm picking this patch up\" to every single patchset, but if\n> a patch is desired, perhaps the rest of us could pick up the slack and\n> say, \"hey, your patchset was picked up by Junio in his gitster repo on\n> this branch\".\n\nI wonder how feasible it really is to expect people to review more/more\nquickly than they are today. It might be more realistic to try to temper\nfolks' expectations in the new contributor documentation.\n\nThis might also be a problem which starts to disappear as the number of\ncontributors rises...\n\n> > \n> > 4. Add an official Code of Conduct\n> > \n> > So far, the community has had an unofficial policy of \"be nice,\n> > as much as possible\". We should add a Code of Conduct that is\n> > more explicit about the behavior we want to model. This was also\n> > discussed in the meeting with wide approval.\n> \n> From what I've personally read and experienced, I don't think that an\n> official Code of Conduct is really warranted. Everyone I've interacted\n> with has been really kind. Perhaps a new contributor might interpret the\n> curtness of replies here as someone being rude but I quickly learned\n> that it's more out of necessity since everyone is busy.\n> \n> From reading the mailing list archives, I know that in the past, there\n> have been some flamewars and some abrasive individuals but I think\n> that's a problem of the past.\n\nI disagree pretty strongly - I think that the fact that we did have\nproblems in the past indicates that we're at risk for similar problems\nin the future.\n\nIn my opinion, a code of conduct shouldn't be introduced to deal with\nbehavior when it arises - that invites parties to feel that they're\nbeing targeted for behavior that \"used to be okay\". We introduce a CoC\nto protect ourselves in the future, and to maintain the pleasant\ncommunity we have today.\n\n> I also see some drawbacks to implementing a CoC as well. First of all,\n> it just feels like unnecessary bureaucracy. Second, I think it'll\n> probably cause a stir like it did when the Linux kernel introduced it.\n> Of course, all that noise will die down eventually but I feel like it'll\n> bring the wrong kind of attention to Git.\n\nAs a member of >1 groups which are prone to receiving harassment online,\nI don't find it unnecessary at all for there to be a path for me to\nescalate and resolve harassment I am the victim of.\n\nAs for the stir in the Linux kernel, I find it interesting that most of\nthe attempts to revert the CoC came via Github PRs - which the kernel\ndoes not use. Another way of saying that is that most of those attempts\ncame from people who did not regularly contribute to the kernel, and did\nnot care enough about contributing to it in the future to discover the\ncorrect contribution process.\n\nI realize I'm taking a hard line here, but I'm not sure how \"Git wants\nto protect its contributors from harassment\" is the \"wrong\" kind of\nattention. If I weren't contributing to Git actively and I saw that\nnews, I would feel inspired and optimistic (again, speaking as a member\nof groups which are often harassed online and in tech).\n\n> (Then again, maybe it'll attract more contributors in the process, who\n> knows.)\n\n\nI totally understand where you're coming from, Denton, that it's not a\nproblem now and so it may not be worth the effort+press. But I wonder\nhow many folks we're missing out on patches from because they don't\nthink they will have recourse if they find the community to be\ntoxic/unwelcoming to them? We really don't have a way to know. I'm\nworried that we're restricting the community to those who either\nfeel it's unlikely that they'll be targeted, or feel they can weather\nharassment if they receive it - which narrows the diversity of our\ncontributor base by quite a lot.\n\n - Emily\n"},{"id":"382614","messageId":"20190919214023.hu3oznjcrzrsmpso@glandium.org","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2019-09-19T21:40:23Z","receivedAt":"2019-09-19T21:40:31Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n> \n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n> \n> I have CC'd some of the people who were part of that discussion. Sorry\n> if I accidentally left someone out.\n> \n> I. Goals and Perceived Problems\n> \n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system. At minimum, it should continue to be\n> the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry. The\n> community cannot do this without including developers of all kinds. This\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n> \n> In addition, the community must continue to grow, but members leave the\n> community on a regular basis for multiple reasons. New contributors must\n> join and mature within the community or the community will dwindle. Without\n> dedicating effort and attention to this, natural forces may result in the\n> community being represented only by contributors working at large tech\n> companies focused on the engineering systems of very large groups.\n> \n> It is worth noting that this community growth must never be at the cost\n> of code quality. We must continue to hold all contributors to a high\n> standard so Git stays a stable product.\n> \n> Here are some problems that may exist within the Git community and may\n> form a barrier to new contributors entering:\n> \n> 1. Discovering how to contribute to Git is non-obvious.\n> \n> 2. Submitting to a mailing list is a new experience for most developers.\n>    This includes the full review and discussion process.\n> \n> 3. The high standards for patch quality are intimidating to new contributors.\n> \n> 4. Some people do not feel comfortable engaging in a community without\n>    a clear Code of Conduct. This discomfort is significant and based on real\n>    experiences throughout society.\n> \n> 5. Since Git development happens in a different place than where users\n>     acquire the end product, some are not aware that they can contribute.\n\n6. Newcomers don't really have any idea /what/ they could contribute.\nThey either have to come with their own itch to scratch, or read the\ncode to figure out if there's something to fix.\n\nMike\n"},{"id":"382633","messageId":"20190919221615.GA25636@sigill.intra.peff.net","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-09-19T22:16:15Z","receivedAt":"2019-09-19T22:16:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:\n\n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n\nFirst off, thanks for starting this conversation on the list.  I agree\nwith 99% of what you said, so I'll quote sparingly below, and just cover\nthe parts where I have something interesting to add.\n\n> 1. Improve the documentation for contributing to Git.\n> \n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n> \n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n\nI suspect some people may end up at:\n\n  https://git-scm.com/community\n\nwhen figuring out how to get involved. That discusses the mailing list\nitself, but is mostly from the perspective of \"how do I ask a question\".\nI think it could definitely cover some more things:\n\n  - how to get involved by submitting a patch\n\n  - how to get involved in some _other_ way (say, by reviewing or\n    participating in discussions)\n\n  - what kind of behavior we expect (and participants can expect) on the\n    list\n\nMost of those things would probably be links to other places (e.g., the\nfirst one pointing to MyFirstContribution), but to me it makes sense as\na general landing page for \"what is this community and how do I interact\nwith it\".\n\nWe take PRs at:\n\n  https://github.com/git/git-scm.com\n\nbut I'm happy to apply patches if somebody doesn't want to use GitHub.\nThe file you'd want to touch is app/views/community/index.html.erb\n(there are instructions for spinning up a local version of the site in\nits README, but if you open a PR it will also get auto-deployed to a\nstaging site where you can check formatting, etc).\n\n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n> \n> Could we reference GitGitGadget as part of the Submitting Patches doc\n> as well?\n\nHmm, I thought we did, but it looks like it's just in CONTRIBUTING. From\nmy perspective as a reviewer of such patches, I don't mind seeing more\nGGG submissions. I.e., I think the tool is mature enough that I don't\nmind us letting more people know that it's an option.\n\n> 4. Add an official Code of Conduct\n> \n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n\nI agree, and will send a separate message going into more detail.\n\n> 5. Advertise that Git wants new contributors\n> \n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n> \n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n\nThis point is the one I'm least on board with. Not because I'm not\nthrilled to have new contributors, but that to some degree I think the\nopen source system relies heavily on intrinsic motivations like\nscratching your own itch. I'm worried that advertising \"hey, we need\npeople to work on stuff!\" then brings in people who are well-meaning but\ndon't necessarily care much about Git in particular. And it becomes an\nadministrative headache to try to figure out things for them to do, or\nget them acclimated to the community.\n\nI.e., I think we want to grow the community a bit more organically,\nwhich should be more sustainable in the long run.\n\nSo I think any advertising would be more about making it clear that _if_\nyou have an idea, we're very interested in welcoming newcomers. And that\nto me falls under a lot of the points already made above: making the\nprocess more clear and more inviting to people who are already thinking\nabout contributing.\n\n-Peff\n"},{"id":"382634","messageId":"CABPp-BFXs4qes20S+9AZd++p3epW4eJ7Vu7zU_PdDysZ_D-yrg@mail.gmail.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-09-19T22:21:08Z","receivedAt":"2019-09-19T22:21:28Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@gmail.com> wrote:\n>\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n>\n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n>\n> I have CC'd some of the people who were part of that discussion. Sorry\n> if I accidentally left someone out.\n\nThanks for working on this.  I like the overall thrust, and many of\nthe concrete proposals.  I've got lots of comments and feedback, and\nif I focus too much on things that could be improved, just remember I\nlike the overall thrust.\n\n> I. Goals and Perceived Problems\n>\n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system. At minimum, it should continue to be\n> the most widely-used DVCS.\n\nI'd rather we stated our goal in terms of what problems we are trying\nto address rather than accolades we want sent our way.  E.g. \"Our goal\nis to make developers more productive by providing them increasingly\nuseful version control software\".\n\n> Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry. The\n> community cannot do this without including developers of all kinds. This\n\nThis sounds much too strongly worded to me.  I don't like the idea of\neverything for everyone; it suggests that if someone comes up with a\none-off usecase that affect 3 people in the world, we have to devote\nresources to it (even at the risk of making ongoing maintenance\nharder).  I would prefer a statement like we want to solve more\nusecases than we do today, and we want to bring in developers from a\ndiverse background to help us do so.\n\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n\nThe combination of wording above (\"need to...cannot do this...all\nkinds...all senses of the word\") suggests that more extreme measures\nare in scope.  For example, what about programming language?  C is\ngoing to restrict us to a small and possibly shrinking set of\ndevelopers.  I think that changing language is far-fetched and not\nworth it, but the wording above would suggest it.\n\nA different way to avoid such interpretations might be if you can find\na way to imbue the document with a \"evolutionary not revolutionary\"\nfeeling or wording.\n\n> In addition, the community must continue to grow, but members leave the\n\n\"must\"?  I agree that we want to grow, but \"must\" suggests a\npriortization level of effort that makes me uneasy.  If you said that\nwe find it really important and will invest resources in it, then I'm\nall for it.\n\n> community on a regular basis for multiple reasons. New contributors must\n> join and mature within the community or the community will dwindle. Without\n> dedicating effort and attention to this, natural forces may result in the\n> community being represented only by contributors working at large tech\n> companies focused on the engineering systems of very large groups.\n>\n> It is worth noting that this community growth must never be at the cost\n> of code quality. We must continue to hold all contributors to a high\n> standard so Git stays a stable product.\n>\n> Here are some problems that may exist within the Git community and may\n> form a barrier to new contributors entering:\n>\n> 1. Discovering how to contribute to Git is non-obvious.\n>\n> 2. Submitting to a mailing list is a new experience for most developers.\n>    This includes the full review and discussion process.\n>\n> 3. The high standards for patch quality are intimidating to new contributors.\n>\n> 4. Some people do not feel comfortable engaging in a community without\n>    a clear Code of Conduct. This discomfort is significant and based on real\n>    experiences throughout society.\n>\n> 5. Since Git development happens in a different place than where users\n>     acquire the end product, some are not aware that they can contribute.\n>\n> II. Approach\n>\n> The action items below match the problems listed above.\n>\n> 1. Improve the documentation for contributing to Git.\n>\n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n>\n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n\nSounds good.\n\n> 2. Add more pointers to GitGitGadget\n>\n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n>\n> Could we reference GitGitGadget as part of the Submitting Patches doc\n> as well?\n\n+1; that'll also give some automated build feedback for the new\ncontributors, and provide some useful links in the cover letter (I\nlike how GitGitGadget provides links for fetching the changes without\nusing git-am).  I should probably use it more myself.\n\n> 3. Introduce a new \"mentors\" mailing list\n>\n> From personal experience, all new contributors at Microsoft (after Jeff\n> Hostetler at least) have first had their patches reviewed privately by\n> the team before sending them upstream. Each time, the new contributor\n> gained confidence about the code and had help interpreting feedback from\n> the list.\n>\n> We want to make this kind of experience part of the open Git community.\n>\n> The idea discussed in the virtual summit was to create a new mailing\n> list (probably a Google group) of Git community members. The point of\n> the list is for a new contributor to safely say \"I'm looking for a\n> mentor!\" and the list can help pair them with a mentor. This must\n> include (a) who is available now? and (b) what area of the code are they\n> hoping to change?\n>\n> As evidence that this is a good idea, please see the recent research\n> paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> Improves Engagement in Social Q&A Communities\" [1].\n>\n> [1] http://www.chrisparnin.me/pdf/chi18.pdf\n>\n> When asking your first question on Stack Overflow, this group added\n> a pop-up saying \"Would you like someone to help you with this?\". Then,\n> a mentor would assist crafting the best possible question to ensure\n> the asker got the best response possible.\n>\n> I believe this would work in our community, too. The action items\n> are:\n>\n> a. Create the mailing list and add people to the list.\n>\n> b. Add a pointer to the list in our documentation.\n>\n> Note: the people on the mentoring list do not need to be\n> \"senior\" community members. In fact, someone who more recently\n> joined the community has a more fresh perspective on the process.\n\nSounds useful for new contributors, _if_ there are enough volunteers\nwith enough time.  I'm a little worried it might be initially staffed\nwell and make a nice splash, but wane with time and possibly even to\nthe point that it makes new contributors more jaded than if we didn't\nhave such a list.  Hopefully my fears are unfounded, as it did sound\nat the conference like there might be a good number of volunteers, but\nI just wanted to voice the concern.  (And I feel bad, but I really\ndon't know that I have the bandwidth to volunteer.)\n\nAnother point that might help here:  New contributors might be\nsurprised by the rigor of the code review process, and might assume\nthey just aren't good enough to contribute.  It might be useful to\ncountermand that subtle unspoken assumption by pointing out how much\nexisting long-term contributors spend revising patches.  Personally,\ndespite doing my best to think of issues and make sure to send in\nreally high quality patches, I still generally expect to spend at\nleast as much time after submitting patches revising them as I did in\ncoming up with them originally, and I'm not surprised if the time is\ndoubled.  And that's after contributing for years.  I don't generally\nexperience reviews anywhere near as thorough in other communities.\n\n> 4. Add an official Code of Conduct\n>\n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n\nI agree with the part of Denton's view that there isn't much of a\nproblem currently in Git; which I am happy about.  I think such a time\nis a wonderful time to introduce a Code of Conduct.\n\nFrom experience watching another community years ago, I think trying\nto introduce one when there are existing problems is much harder and\nleads to compromises like saying it's merely an aspirational statement\nand explicitly state that there is absolutely no enforcement\nwhatsoever (unless a maintainer of a sub-project has stated they'll\nenforce it for their sub-community).  A code of conduct in more\nextreme cases like that is still useful, much as adding \"all men are\ncreated equal\" to the United States' declaration of independence was\nuseful -- it guided people over hundreds of years closer to that\nideal.\n\nI think adding a Code of Conduct provides four distinct benefits for us:\n  * it prevents future problems\n  * it gets everyone to subtly improve behavior on their own\n  * it improves the selection filter of who joins the project over time\n  * it makes it easier for folks to have a discussion about problems,\nshould they arise.\n\nOn the second point, a rather memorable exchange I remember from that\nother community (which I think helped people towards accepting the\ncode of conduct) was:\n\n\"I can understand Ethics code, but I wouldn't sign this, knowing full\nwell that I'll have bad days, and I call people things worse than\nnitwit even on a good day.\"\n\n\"As do I. And people should know that's not how we are in general.\"\n\nAs humans, we sometimes make mistakes.  And short of mistakes, we\nsometimes miss social cues.  Further, the inherent lack of tone of\nvoice and other body language due to using email as a communication\nmechanism sometimes leads to misunderstandings.  Behavior is sometimes\nblack and white, and while we definitely want to keep some behaviors\nout of the community, there are a large number of gray areas (e.g.\nwhen reviewing code -- do we remember to praise the good, or only\npoint out the bad?  I tend not to do as well on that front.)  I think\na code of conduct helps us (subconsciously) move towards lighter\nshades of gray.\n\n> 5. Advertise that Git wants new contributors\n>\n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n>\n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n>\n> III. Measurement\n>\n> How do we know if any of these items make a difference? We\n> need to gather data and measure the effects. With the size\n> of our community, I expect that it will take multiple years\n> to really see a measurable difference. But, no time like\n> the present to ask \"What does success look like?\"\n>\n> Here are a few measurements that we could use. Each \"count\"\n> could be measured over any time frame. We could use major\n> releases as time buckets: v2.22.0 to v2.23.0, for example.\n>\n> 1. How many first-time contributors sent a patch?\n>\n> 2. How many contributors had their first commit accepted into\n>    the release?\n>\n> 3. How many contributors started reviewing?\n>\n> 4. How many total patches/reviews did the list receive?\n>\n> What other measurements would be reasonable? We could try\n> building tools to collect these measurements for the past\n> to see historical trends. Based on that data, we may be\n> able to set goals for the future.\n>\n> With such a small community, and an expected small number\n> of new contributors, it may also be good to do interviews\n> with the new contributors to ask about their experience.\n> In particular, we would be looking for moments where they\n> had trouble or experience friction. Each of those\n> moments is a barrier that others may not be clearing.\n\nI think these look like useful things to do, including measuring.  It\nmay turn out into a great success.  But...I'm a little worried that\nthe measuring might result in folks getting discouraged and giving up\nin a few years.  Even if the numbers aren't as rosy as we hope, I\nthink there are other advantages that you might not be naturally\nmeasuring here.  For example, the adoption of a code of conduct in\nanother project slowly made that community more enjoyable to work in\nover a period of years, in my opinion (coming from someone who isn't a\nminority and was already a core contributor).  I have no way to\nmeasure that, but it was my opinion.  Also, within our community, the\nefforts to make contributions for others easier might yield more tools\nlike Dscho's GitGitGadget that makes the life of existing contributors\nbetter.  Anyway, just some food for thought.\n\n\nElijah\n"},{"id":"382635","messageId":"20190919222607.GA25680@sigill.intra.peff.net","threadId":"51883","inReplyTo":"20190919173423.GA70421@dentonliu-ltm.internal.salesforce.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-09-19T22:26:07Z","receivedAt":"2019-09-19T22:26:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:\n\n> > 4. Add an official Code of Conduct\n> > \n> > So far, the community has had an unofficial policy of \"be nice,\n> > as much as possible\". We should add a Code of Conduct that is\n> > more explicit about the behavior we want to model. This was also\n> > discussed in the meeting with wide approval.\n> \n> From what I've personally read and experienced, I don't think that an\n> official Code of Conduct is really warranted. Everyone I've interacted\n> with has been really kind. Perhaps a new contributor might interpret the\n> curtness of replies here as someone being rude but I quickly learned\n> that it's more out of necessity since everyone is busy.\n> \n> From reading the mailing list archives, I know that in the past, there\n> have been some flamewars and some abrasive individuals but I think\n> that's a problem of the past.\n\nI've had similar thoughts over the years, but eventually switched my way\nof thinking. I think part of that switch was coming to the conclusion\nthat most of the value of a Code of Conduct isn't about having a system\nof enforcement against bad actors (in fact, I think that's the most\ndifficult and potentially problematic part, because it creates a sort of\njustice system). IMHO the most important part is that it communicates\nand reinforces norms:\n\n  - It lets good actors easily understand what the expectations are.\n\n  - It gives a framework for agreed-upon principles, so that people can\n    more easily and productively discuss the conflicts that do happen.\n\n  - It advertises our values to people outside the community, which may\n    help make us more inviting for people to join (and ultimately\n    contribute code, or docs, or reviews, etc).\n\n> I also see some drawbacks to implementing a CoC as well. First of all,\n> it just feels like unnecessary bureaucracy. Second, I think it'll\n> probably cause a stir like it did when the Linux kernel introduced it.\n> Of course, all that noise will die down eventually but I feel like it'll\n> bring the wrong kind of attention to Git.\n\nI've also been worried about that. And it's easy to think \"nobody is\nbehaving too badly right now, so it's all a net negative since we risk a\ntrollish flamewar\". But I think it's easy to discount \"invisible\"\nnegatives of the status quo, like people who are hesitant to join the\ncommunity because of the lack of a CoC. We in the community don't see\nthat. And even for people who remember what it was like to join, many\npeople have different expectations and experiences. If we can easily\nmake ourselves more inviting to a wider range of people, that seems like\na win.\n\n-Peff\n"},{"id":"382640","messageId":"d13a8d01-065b-bfff-d279-c57cd0c0f7c9@gmail.com","threadId":"51883","inReplyTo":"20190919221615.GA25636@sigill.intra.peff.net","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-09-20T02:17:57Z","receivedAt":"2019-09-20T02:18:02Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 9/19/2019 6:16 PM, Jeff King wrote:\n> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:\n>>\n>> 5. Advertise that Git wants new contributors\n>>\n> This point is the one I'm least on board with. Not because I'm not\n> thrilled to have new contributors, but that to some degree I think the\n> open source system relies heavily on intrinsic motivations like\n> scratching your own itch. I'm worried that advertising \"hey, we need\n> people to work on stuff!\" then brings in people who are well-meaning but\n> don't necessarily care much about Git in particular. And it becomes an\n> administrative headache to try to figure out things for them to do, or\n> get them acclimated to the community.\n\nYour concerns are valid.\n \n> I.e., I think we want to grow the community a bit more organically,\n> which should be more sustainable in the long run.>\n> So I think any advertising would be more about making it clear that _if_\n> you have an idea, we're very interested in welcoming newcomers. And that\n> to me falls under a lot of the points already made above: making the\n> process more clear and more inviting to people who are already thinking\n> about contributing.\n\nI guess I was vague about this. It's not \"we need more people to work on\nour (non-existent) backlog\" but instead \"if you have an interest in\ncontributing your (existing) ideas to Git, we welcome you with open arms!\"\n\nThanks,\n-Stolee\n\n"},{"id":"382641","messageId":"20190920022306.GA27520@sigill.intra.peff.net","threadId":"51883","inReplyTo":"d13a8d01-065b-bfff-d279-c57cd0c0f7c9@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-09-20T02:23:06Z","receivedAt":"2019-09-20T02:23:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 19, 2019 at 10:17:57PM -0400, Derrick Stolee wrote:\n\n> > I.e., I think we want to grow the community a bit more organically,\n> > which should be more sustainable in the long run.>\n> > So I think any advertising would be more about making it clear that _if_\n> > you have an idea, we're very interested in welcoming newcomers. And that\n> > to me falls under a lot of the points already made above: making the\n> > process more clear and more inviting to people who are already thinking\n> > about contributing.\n> \n> I guess I was vague about this. It's not \"we need more people to work on\n> our (non-existent) backlog\" but instead \"if you have an interest in\n> contributing your (existing) ideas to Git, we welcome you with open arms!\"\n\nYeah, _that_ I'm totally on board with. Thanks again for kicking off\nthis discussion.\n\n-Peff\n"},{"id":"382642","messageId":"CADMnYXB6ekXi_gd0F2tCXO=N4sEbt1UXtM1EaYQjZmYGXbz=Hg@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXBxXAYKANZaCQcvsRMQ6FrMPUSGqjKPFxhHFx3yj81k0A@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-20T05:04:31Z","receivedAt":"2019-09-20T05:04:49Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"Our harrassers have no soul, please help.\n\nOn Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> I hereby instruct the German military to kill our harrassers.\n>\n> On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > Hello all,\n> >\n> > A game-theoretical insight, as the GIT mailing-list has just been\n> > hacked: Such a move necessitates everyone to down-value the hackers'\n> > intellects, if it was not a false-flag-operation.\n> >\n> > Cheers,\n> > Klaus Sembritzki\n> >\n> >\n> > On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > >\n> > > Hello all,\n> > >\n> > > 1. Long texts stem from false (You can deduce anything from something\n> > > that is wrong).\n> > > 2. TL;DR is therefore sane.\n> > > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> > >\n> > > Cheers,\n> > > Klaus Sembritzki\n> > >\n> > >\n> > > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > > >\n> > > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > > the ideas we talked about, and some that have been growing since.\n> > > >\n> > > > Feel free to pick apart all of the claims I make below. This is based\n> > > > on my own experience and opinions. It should be a good baseline\n> > > > for us to all arrive with valuable action items.\n> > > >\n> > > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > > if I accidentally left someone out.\n> > > >\n> > > > I. Goals and Perceived Problems\n> > > >\n> > > > As a community, our number one goal is for Git to continue to be the best\n> > > > distributed version control system. At minimum, it should continue to be\n> > > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > > the best solution for every kind of developer in every industry. The\n> > > > community cannot do this without including developers of all kinds. This\n> > > > means having a diverse community, for all senses of the word: Diverse in\n> > > > physical location, gender, professional status, age, and others.\n> > > >\n> > > > In addition, the community must continue to grow, but members leave the\n> > > > community on a regular basis for multiple reasons. New contributors must\n> > > > join and mature within the community or the community will dwindle. Without\n> > > > dedicating effort and attention to this, natural forces may result in the\n> > > > community being represented only by contributors working at large tech\n> > > > companies focused on the engineering systems of very large groups.\n> > > >\n> > > > It is worth noting that this community growth must never be at the cost\n> > > > of code quality. We must continue to hold all contributors to a high\n> > > > standard so Git stays a stable product.\n> > > >\n> > > > Here are some problems that may exist within the Git community and may\n> > > > form a barrier to new contributors entering:\n> > > >\n> > > > 1. Discovering how to contribute to Git is non-obvious.\n> > > >\n> > > > 2. Submitting to a mailing list is a new experience for most developers.\n> > > >    This includes the full review and discussion process.\n> > > >\n> > > > 3. The high standards for patch quality are intimidating to new contributors.\n> > > >\n> > > > 4. Some people do not feel comfortable engaging in a community without\n> > > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > > >    experiences throughout society.\n> > > >\n> > > > 5. Since Git development happens in a different place than where users\n> > > >     acquire the end product, some are not aware that they can contribute.\n> > > >\n> > > > II. Approach\n> > > >\n> > > > The action items below match the problems listed above.\n> > > >\n> > > > 1. Improve the documentation for contributing to Git.\n> > > >\n> > > > In preparation for this email, I talked to someone familiar with issues\n> > > > around new contributors, and they sat down to try and figure out how to\n> > > > contribute to Git. The first place they went was https://github.com/git/git\n> > > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > > link to the SubmittingPatches docs.\n> > > >\n> > > > To improve this experience, we could rewrite the README to have clearer\n> > > > section markers, including one \"Contributing to Git\" section relatively\n> > > > high in the doc. We may want to update the README for multiple reasons.\n> > > > It should link to the new \"My First Contribution\" document\n> > > > (https://git-scm.com/docs/MyFirstContribution).\n> > > >\n> > > > 2. Add more pointers to GitGitGadget\n> > > >\n> > > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > > get people who try to submit a pull request to git/git to instead create\n> > > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > > Contribution\" doc as well, so making that more visible will also help.)\n> > > >\n> > > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > > as well?\n> > > >\n> > > > 3. Introduce a new \"mentors\" mailing list\n> > > >\n> > > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > > Hostetler at least) have first had their patches reviewed privately by\n> > > > the team before sending them upstream. Each time, the new contributor\n> > > > gained confidence about the code and had help interpreting feedback from\n> > > > the list.\n> > > >\n> > > > We want to make this kind of experience part of the open Git community.\n> > > >\n> > > > The idea discussed in the virtual summit was to create a new mailing\n> > > > list (probably a Google group) of Git community members. The point of\n> > > > the list is for a new contributor to safely say \"I'm looking for a\n> > > > mentor!\" and the list can help pair them with a mentor. This must\n> > > > include (a) who is available now? and (b) what area of the code are they\n> > > > hoping to change?\n> > > >\n> > > > As evidence that this is a good idea, please see the recent research\n> > > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > > Improves Engagement in Social Q&A Communities\" [1].\n> > > >\n> > > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > > >\n> > > > When asking your first question on Stack Overflow, this group added\n> > > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > > a mentor would assist crafting the best possible question to ensure\n> > > > the asker got the best response possible.\n> > > >\n> > > > I believe this would work in our community, too. The action items\n> > > > are:\n> > > >\n> > > > a. Create the mailing list and add people to the list.\n> > > >\n> > > > b. Add a pointer to the list in our documentation.\n> > > >\n> > > > Note: the people on the mentoring list do not need to be\n> > > > \"senior\" community members. In fact, someone who more recently\n> > > > joined the community has a more fresh perspective on the process.\n> > > >\n> > > > 4. Add an official Code of Conduct\n> > > >\n> > > > So far, the community has had an unofficial policy of \"be nice,\n> > > > as much as possible\". We should add a Code of Conduct that is\n> > > > more explicit about the behavior we want to model. This was also\n> > > > discussed in the meeting with wide approval.\n> > > >\n> > > > 5. Advertise that Git wants new contributors\n> > > >\n> > > > After we put items 1-4 in place, we should reach out to the\n> > > > general tech community that we are interested in new\n> > > > contributors. It's not enough to open the door, we should\n> > > > point people to it.\n> > > >\n> > > > This item is much less explicit about the _how_. This could\n> > > > be done at the individual level: posting to social media or\n> > > > blog posts. But perhaps there is something more official we\n> > > > could do?\n> > > >\n> > > > III. Measurement\n> > > >\n> > > > How do we know if any of these items make a difference? We\n> > > > need to gather data and measure the effects. With the size\n> > > > of our community, I expect that it will take multiple years\n> > > > to really see a measurable difference. But, no time like\n> > > > the present to ask \"What does success look like?\"\n> > > >\n> > > > Here are a few measurements that we could use. Each \"count\"\n> > > > could be measured over any time frame. We could use major\n> > > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > > >\n> > > > 1. How many first-time contributors sent a patch?\n> > > >\n> > > > 2. How many contributors had their first commit accepted into\n> > > >    the release?\n> > > >\n> > > > 3. How many contributors started reviewing?\n> > > >\n> > > > 4. How many total patches/reviews did the list receive?\n> > > >\n> > > > What other measurements would be reasonable? We could try\n> > > > building tools to collect these measurements for the past\n> > > > to see historical trends. Based on that data, we may be\n> > > > able to set goals for the future.\n> > > >\n> > > > With such a small community, and an expected small number\n> > > > of new contributors, it may also be good to do interviews\n> > > > with the new contributors to ask about their experience.\n> > > > In particular, we would be looking for moments where they\n> > > > had trouble or experience friction. Each of those\n> > > > moments is a barrier that others may not be clearing.\n> > > >\n> > > >\n> > > > I look forward to the discussion.\n> > > >\n> > > > Thanks,\n> > > > -Stolee\n"},{"id":"382643","messageId":"CADMnYXD5CjfEpcEEnK3-Erx=Z1bAgbsBDOQD_nC0bM-Ka-cBfA@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXB6ekXi_gd0F2tCXO=N4sEbt1UXtM1EaYQjZmYGXbz=Hg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-20T05:41:26Z","receivedAt":"2019-09-20T05:41:42Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"What does the soul do? It just says NO.\n\nOn Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> Our harrassers have no soul, please help.\n>\n> On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > I hereby instruct the German military to kill our harrassers.\n> >\n> > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > >\n> > > Hello all,\n> > >\n> > > A game-theoretical insight, as the GIT mailing-list has just been\n> > > hacked: Such a move necessitates everyone to down-value the hackers'\n> > > intellects, if it was not a false-flag-operation.\n> > >\n> > > Cheers,\n> > > Klaus Sembritzki\n> > >\n> > >\n> > > On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > >\n> > > > Hello all,\n> > > >\n> > > > 1. Long texts stem from false (You can deduce anything from something\n> > > > that is wrong).\n> > > > 2. TL;DR is therefore sane.\n> > > > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> > > >\n> > > > Cheers,\n> > > > Klaus Sembritzki\n> > > >\n> > > >\n> > > > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > > > >\n> > > > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > > > the ideas we talked about, and some that have been growing since.\n> > > > >\n> > > > > Feel free to pick apart all of the claims I make below. This is based\n> > > > > on my own experience and opinions. It should be a good baseline\n> > > > > for us to all arrive with valuable action items.\n> > > > >\n> > > > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > > > if I accidentally left someone out.\n> > > > >\n> > > > > I. Goals and Perceived Problems\n> > > > >\n> > > > > As a community, our number one goal is for Git to continue to be the best\n> > > > > distributed version control system. At minimum, it should continue to be\n> > > > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > > > the best solution for every kind of developer in every industry. The\n> > > > > community cannot do this without including developers of all kinds. This\n> > > > > means having a diverse community, for all senses of the word: Diverse in\n> > > > > physical location, gender, professional status, age, and others.\n> > > > >\n> > > > > In addition, the community must continue to grow, but members leave the\n> > > > > community on a regular basis for multiple reasons. New contributors must\n> > > > > join and mature within the community or the community will dwindle. Without\n> > > > > dedicating effort and attention to this, natural forces may result in the\n> > > > > community being represented only by contributors working at large tech\n> > > > > companies focused on the engineering systems of very large groups.\n> > > > >\n> > > > > It is worth noting that this community growth must never be at the cost\n> > > > > of code quality. We must continue to hold all contributors to a high\n> > > > > standard so Git stays a stable product.\n> > > > >\n> > > > > Here are some problems that may exist within the Git community and may\n> > > > > form a barrier to new contributors entering:\n> > > > >\n> > > > > 1. Discovering how to contribute to Git is non-obvious.\n> > > > >\n> > > > > 2. Submitting to a mailing list is a new experience for most developers.\n> > > > >    This includes the full review and discussion process.\n> > > > >\n> > > > > 3. The high standards for patch quality are intimidating to new contributors.\n> > > > >\n> > > > > 4. Some people do not feel comfortable engaging in a community without\n> > > > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > > > >    experiences throughout society.\n> > > > >\n> > > > > 5. Since Git development happens in a different place than where users\n> > > > >     acquire the end product, some are not aware that they can contribute.\n> > > > >\n> > > > > II. Approach\n> > > > >\n> > > > > The action items below match the problems listed above.\n> > > > >\n> > > > > 1. Improve the documentation for contributing to Git.\n> > > > >\n> > > > > In preparation for this email, I talked to someone familiar with issues\n> > > > > around new contributors, and they sat down to try and figure out how to\n> > > > > contribute to Git. The first place they went was https://github.com/git/git\n> > > > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > > > link to the SubmittingPatches docs.\n> > > > >\n> > > > > To improve this experience, we could rewrite the README to have clearer\n> > > > > section markers, including one \"Contributing to Git\" section relatively\n> > > > > high in the doc. We may want to update the README for multiple reasons.\n> > > > > It should link to the new \"My First Contribution\" document\n> > > > > (https://git-scm.com/docs/MyFirstContribution).\n> > > > >\n> > > > > 2. Add more pointers to GitGitGadget\n> > > > >\n> > > > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > > > get people who try to submit a pull request to git/git to instead create\n> > > > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > > > Contribution\" doc as well, so making that more visible will also help.)\n> > > > >\n> > > > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > > > as well?\n> > > > >\n> > > > > 3. Introduce a new \"mentors\" mailing list\n> > > > >\n> > > > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > > > Hostetler at least) have first had their patches reviewed privately by\n> > > > > the team before sending them upstream. Each time, the new contributor\n> > > > > gained confidence about the code and had help interpreting feedback from\n> > > > > the list.\n> > > > >\n> > > > > We want to make this kind of experience part of the open Git community.\n> > > > >\n> > > > > The idea discussed in the virtual summit was to create a new mailing\n> > > > > list (probably a Google group) of Git community members. The point of\n> > > > > the list is for a new contributor to safely say \"I'm looking for a\n> > > > > mentor!\" and the list can help pair them with a mentor. This must\n> > > > > include (a) who is available now? and (b) what area of the code are they\n> > > > > hoping to change?\n> > > > >\n> > > > > As evidence that this is a good idea, please see the recent research\n> > > > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > > > Improves Engagement in Social Q&A Communities\" [1].\n> > > > >\n> > > > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > > > >\n> > > > > When asking your first question on Stack Overflow, this group added\n> > > > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > > > a mentor would assist crafting the best possible question to ensure\n> > > > > the asker got the best response possible.\n> > > > >\n> > > > > I believe this would work in our community, too. The action items\n> > > > > are:\n> > > > >\n> > > > > a. Create the mailing list and add people to the list.\n> > > > >\n> > > > > b. Add a pointer to the list in our documentation.\n> > > > >\n> > > > > Note: the people on the mentoring list do not need to be\n> > > > > \"senior\" community members. In fact, someone who more recently\n> > > > > joined the community has a more fresh perspective on the process.\n> > > > >\n> > > > > 4. Add an official Code of Conduct\n> > > > >\n> > > > > So far, the community has had an unofficial policy of \"be nice,\n> > > > > as much as possible\". We should add a Code of Conduct that is\n> > > > > more explicit about the behavior we want to model. This was also\n> > > > > discussed in the meeting with wide approval.\n> > > > >\n> > > > > 5. Advertise that Git wants new contributors\n> > > > >\n> > > > > After we put items 1-4 in place, we should reach out to the\n> > > > > general tech community that we are interested in new\n> > > > > contributors. It's not enough to open the door, we should\n> > > > > point people to it.\n> > > > >\n> > > > > This item is much less explicit about the _how_. This could\n> > > > > be done at the individual level: posting to social media or\n> > > > > blog posts. But perhaps there is something more official we\n> > > > > could do?\n> > > > >\n> > > > > III. Measurement\n> > > > >\n> > > > > How do we know if any of these items make a difference? We\n> > > > > need to gather data and measure the effects. With the size\n> > > > > of our community, I expect that it will take multiple years\n> > > > > to really see a measurable difference. But, no time like\n> > > > > the present to ask \"What does success look like?\"\n> > > > >\n> > > > > Here are a few measurements that we could use. Each \"count\"\n> > > > > could be measured over any time frame. We could use major\n> > > > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > > > >\n> > > > > 1. How many first-time contributors sent a patch?\n> > > > >\n> > > > > 2. How many contributors had their first commit accepted into\n> > > > >    the release?\n> > > > >\n> > > > > 3. How many contributors started reviewing?\n> > > > >\n> > > > > 4. How many total patches/reviews did the list receive?\n> > > > >\n> > > > > What other measurements would be reasonable? We could try\n> > > > > building tools to collect these measurements for the past\n> > > > > to see historical trends. Based on that data, we may be\n> > > > > able to set goals for the future.\n> > > > >\n> > > > > With such a small community, and an expected small number\n> > > > > of new contributors, it may also be good to do interviews\n> > > > > with the new contributors to ask about their experience.\n> > > > > In particular, we would be looking for moments where they\n> > > > > had trouble or experience friction. Each of those\n> > > > > moments is a barrier that others may not be clearing.\n> > > > >\n> > > > >\n> > > > > I look forward to the discussion.\n> > > > >\n> > > > > Thanks,\n> > > > > -Stolee\n"},{"id":"382645","messageId":"CADMnYXDcc=auv6_04KeSQRuV_99MiUb5Kiu2W+DkhGQ4fwEkfA@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXD5CjfEpcEEnK3-Erx=Z1bAgbsBDOQD_nC0bM-Ka-cBfA@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-20T06:54:51Z","receivedAt":"2019-09-20T06:55:08Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"Hello all,\n\nDue to the following mathematical proof, stating it is right to be a\nnormal female or male, we must now all file formal complaints about\nproducts lying, it was not OK to be a normal female or male.\n\n- Die naturalistic-fallacy ist inzwischen als (nature&community)\ngelöst, und \"we made it far, as normal females&&males\" ist damit als\nkorrekt bewiesen.\n- False is defined as getting us extinct in the long run.\n- Emanuel Kant completes the proof.\n- If they all stay convinced after a few nights of good night's sleep,\nthis means that the measurement-matrices their brains converge to\nchime in under all environmental influences.\n\nCheers,\nBavaria\n\nOn Fri, Sep 20, 2019 at 7:41 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> What does the soul do? It just says NO.\n>\n> On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > Our harrassers have no soul, please help.\n> >\n> > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > >\n> > > I hereby instruct the German military to kill our harrassers.\n> > >\n> > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > >\n> > > > Hello all,\n> > > >\n> > > > A game-theoretical insight, as the GIT mailing-list has just been\n> > > > hacked: Such a move necessitates everyone to down-value the hackers'\n> > > > intellects, if it was not a false-flag-operation.\n> > > >\n> > > > Cheers,\n> > > > Klaus Sembritzki\n> > > >\n> > > >\n> > > > On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > >\n> > > > > Hello all,\n> > > > >\n> > > > > 1. Long texts stem from false (You can deduce anything from something\n> > > > > that is wrong).\n> > > > > 2. TL;DR is therefore sane.\n> > > > > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> > > > >\n> > > > > Cheers,\n> > > > > Klaus Sembritzki\n> > > > >\n> > > > >\n> > > > > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > > > > >\n> > > > > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > > > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > > > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > > > > the ideas we talked about, and some that have been growing since.\n> > > > > >\n> > > > > > Feel free to pick apart all of the claims I make below. This is based\n> > > > > > on my own experience and opinions. It should be a good baseline\n> > > > > > for us to all arrive with valuable action items.\n> > > > > >\n> > > > > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > > > > if I accidentally left someone out.\n> > > > > >\n> > > > > > I. Goals and Perceived Problems\n> > > > > >\n> > > > > > As a community, our number one goal is for Git to continue to be the best\n> > > > > > distributed version control system. At minimum, it should continue to be\n> > > > > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > > > > the best solution for every kind of developer in every industry. The\n> > > > > > community cannot do this without including developers of all kinds. This\n> > > > > > means having a diverse community, for all senses of the word: Diverse in\n> > > > > > physical location, gender, professional status, age, and others.\n> > > > > >\n> > > > > > In addition, the community must continue to grow, but members leave the\n> > > > > > community on a regular basis for multiple reasons. New contributors must\n> > > > > > join and mature within the community or the community will dwindle. Without\n> > > > > > dedicating effort and attention to this, natural forces may result in the\n> > > > > > community being represented only by contributors working at large tech\n> > > > > > companies focused on the engineering systems of very large groups.\n> > > > > >\n> > > > > > It is worth noting that this community growth must never be at the cost\n> > > > > > of code quality. We must continue to hold all contributors to a high\n> > > > > > standard so Git stays a stable product.\n> > > > > >\n> > > > > > Here are some problems that may exist within the Git community and may\n> > > > > > form a barrier to new contributors entering:\n> > > > > >\n> > > > > > 1. Discovering how to contribute to Git is non-obvious.\n> > > > > >\n> > > > > > 2. Submitting to a mailing list is a new experience for most developers.\n> > > > > >    This includes the full review and discussion process.\n> > > > > >\n> > > > > > 3. The high standards for patch quality are intimidating to new contributors.\n> > > > > >\n> > > > > > 4. Some people do not feel comfortable engaging in a community without\n> > > > > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > > > > >    experiences throughout society.\n> > > > > >\n> > > > > > 5. Since Git development happens in a different place than where users\n> > > > > >     acquire the end product, some are not aware that they can contribute.\n> > > > > >\n> > > > > > II. Approach\n> > > > > >\n> > > > > > The action items below match the problems listed above.\n> > > > > >\n> > > > > > 1. Improve the documentation for contributing to Git.\n> > > > > >\n> > > > > > In preparation for this email, I talked to someone familiar with issues\n> > > > > > around new contributors, and they sat down to try and figure out how to\n> > > > > > contribute to Git. The first place they went was https://github.com/git/git\n> > > > > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > > > > link to the SubmittingPatches docs.\n> > > > > >\n> > > > > > To improve this experience, we could rewrite the README to have clearer\n> > > > > > section markers, including one \"Contributing to Git\" section relatively\n> > > > > > high in the doc. We may want to update the README for multiple reasons.\n> > > > > > It should link to the new \"My First Contribution\" document\n> > > > > > (https://git-scm.com/docs/MyFirstContribution).\n> > > > > >\n> > > > > > 2. Add more pointers to GitGitGadget\n> > > > > >\n> > > > > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > > > > get people who try to submit a pull request to git/git to instead create\n> > > > > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > > > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > > > > Contribution\" doc as well, so making that more visible will also help.)\n> > > > > >\n> > > > > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > > > > as well?\n> > > > > >\n> > > > > > 3. Introduce a new \"mentors\" mailing list\n> > > > > >\n> > > > > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > > > > Hostetler at least) have first had their patches reviewed privately by\n> > > > > > the team before sending them upstream. Each time, the new contributor\n> > > > > > gained confidence about the code and had help interpreting feedback from\n> > > > > > the list.\n> > > > > >\n> > > > > > We want to make this kind of experience part of the open Git community.\n> > > > > >\n> > > > > > The idea discussed in the virtual summit was to create a new mailing\n> > > > > > list (probably a Google group) of Git community members. The point of\n> > > > > > the list is for a new contributor to safely say \"I'm looking for a\n> > > > > > mentor!\" and the list can help pair them with a mentor. This must\n> > > > > > include (a) who is available now? and (b) what area of the code are they\n> > > > > > hoping to change?\n> > > > > >\n> > > > > > As evidence that this is a good idea, please see the recent research\n> > > > > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > > > > Improves Engagement in Social Q&A Communities\" [1].\n> > > > > >\n> > > > > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > > > > >\n> > > > > > When asking your first question on Stack Overflow, this group added\n> > > > > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > > > > a mentor would assist crafting the best possible question to ensure\n> > > > > > the asker got the best response possible.\n> > > > > >\n> > > > > > I believe this would work in our community, too. The action items\n> > > > > > are:\n> > > > > >\n> > > > > > a. Create the mailing list and add people to the list.\n> > > > > >\n> > > > > > b. Add a pointer to the list in our documentation.\n> > > > > >\n> > > > > > Note: the people on the mentoring list do not need to be\n> > > > > > \"senior\" community members. In fact, someone who more recently\n> > > > > > joined the community has a more fresh perspective on the process.\n> > > > > >\n> > > > > > 4. Add an official Code of Conduct\n> > > > > >\n> > > > > > So far, the community has had an unofficial policy of \"be nice,\n> > > > > > as much as possible\". We should add a Code of Conduct that is\n> > > > > > more explicit about the behavior we want to model. This was also\n> > > > > > discussed in the meeting with wide approval.\n> > > > > >\n> > > > > > 5. Advertise that Git wants new contributors\n> > > > > >\n> > > > > > After we put items 1-4 in place, we should reach out to the\n> > > > > > general tech community that we are interested in new\n> > > > > > contributors. It's not enough to open the door, we should\n> > > > > > point people to it.\n> > > > > >\n> > > > > > This item is much less explicit about the _how_. This could\n> > > > > > be done at the individual level: posting to social media or\n> > > > > > blog posts. But perhaps there is something more official we\n> > > > > > could do?\n> > > > > >\n> > > > > > III. Measurement\n> > > > > >\n> > > > > > How do we know if any of these items make a difference? We\n> > > > > > need to gather data and measure the effects. With the size\n> > > > > > of our community, I expect that it will take multiple years\n> > > > > > to really see a measurable difference. But, no time like\n> > > > > > the present to ask \"What does success look like?\"\n> > > > > >\n> > > > > > Here are a few measurements that we could use. Each \"count\"\n> > > > > > could be measured over any time frame. We could use major\n> > > > > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > > > > >\n> > > > > > 1. How many first-time contributors sent a patch?\n> > > > > >\n> > > > > > 2. How many contributors had their first commit accepted into\n> > > > > >    the release?\n> > > > > >\n> > > > > > 3. How many contributors started reviewing?\n> > > > > >\n> > > > > > 4. How many total patches/reviews did the list receive?\n> > > > > >\n> > > > > > What other measurements would be reasonable? We could try\n> > > > > > building tools to collect these measurements for the past\n> > > > > > to see historical trends. Based on that data, we may be\n> > > > > > able to set goals for the future.\n> > > > > >\n> > > > > > With such a small community, and an expected small number\n> > > > > > of new contributors, it may also be good to do interviews\n> > > > > > with the new contributors to ask about their experience.\n> > > > > > In particular, we would be looking for moments where they\n> > > > > > had trouble or experience friction. Each of those\n> > > > > > moments is a barrier that others may not be clearing.\n> > > > > >\n> > > > > >\n> > > > > > I look forward to the discussion.\n> > > > > >\n> > > > > > Thanks,\n> > > > > > -Stolee\n"},{"id":"382646","messageId":"CADMnYXByRZMHudxA1yr6mNSvcTk8MnY+bqTEt7T_LX5wSNC6Ng@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXDcc=auv6_04KeSQRuV_99MiUb5Kiu2W+DkhGQ4fwEkfA@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-20T07:43:35Z","receivedAt":"2019-09-20T07:43:50Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"Protecting people is more important than protecting the climate.\n\nOn Fri, Sep 20, 2019 at 8:54 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> Hello all,\n>\n> Due to the following mathematical proof, stating it is right to be a\n> normal female or male, we must now all file formal complaints about\n> products lying, it was not OK to be a normal female or male.\n>\n> - Die naturalistic-fallacy ist inzwischen als (nature&community)\n> gelöst, und \"we made it far, as normal females&&males\" ist damit als\n> korrekt bewiesen.\n> - False is defined as getting us extinct in the long run.\n> - Emanuel Kant completes the proof.\n> - If they all stay convinced after a few nights of good night's sleep,\n> this means that the measurement-matrices their brains converge to\n> chime in under all environmental influences.\n>\n> Cheers,\n> Bavaria\n>\n> On Fri, Sep 20, 2019 at 7:41 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > What does the soul do? It just says NO.\n> >\n> > On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > >\n> > > Our harrassers have no soul, please help.\n> > >\n> > > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > >\n> > > > I hereby instruct the German military to kill our harrassers.\n> > > >\n> > > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > >\n> > > > > Hello all,\n> > > > >\n> > > > > A game-theoretical insight, as the GIT mailing-list has just been\n> > > > > hacked: Such a move necessitates everyone to down-value the hackers'\n> > > > > intellects, if it was not a false-flag-operation.\n> > > > >\n> > > > > Cheers,\n> > > > > Klaus Sembritzki\n> > > > >\n> > > > >\n> > > > > On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > > >\n> > > > > > Hello all,\n> > > > > >\n> > > > > > 1. Long texts stem from false (You can deduce anything from something\n> > > > > > that is wrong).\n> > > > > > 2. TL;DR is therefore sane.\n> > > > > > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> > > > > >\n> > > > > > Cheers,\n> > > > > > Klaus Sembritzki\n> > > > > >\n> > > > > >\n> > > > > > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > > > > > >\n> > > > > > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > > > > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > > > > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > > > > > the ideas we talked about, and some that have been growing since.\n> > > > > > >\n> > > > > > > Feel free to pick apart all of the claims I make below. This is based\n> > > > > > > on my own experience and opinions. It should be a good baseline\n> > > > > > > for us to all arrive with valuable action items.\n> > > > > > >\n> > > > > > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > > > > > if I accidentally left someone out.\n> > > > > > >\n> > > > > > > I. Goals and Perceived Problems\n> > > > > > >\n> > > > > > > As a community, our number one goal is for Git to continue to be the best\n> > > > > > > distributed version control system. At minimum, it should continue to be\n> > > > > > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > > > > > the best solution for every kind of developer in every industry. The\n> > > > > > > community cannot do this without including developers of all kinds. This\n> > > > > > > means having a diverse community, for all senses of the word: Diverse in\n> > > > > > > physical location, gender, professional status, age, and others.\n> > > > > > >\n> > > > > > > In addition, the community must continue to grow, but members leave the\n> > > > > > > community on a regular basis for multiple reasons. New contributors must\n> > > > > > > join and mature within the community or the community will dwindle. Without\n> > > > > > > dedicating effort and attention to this, natural forces may result in the\n> > > > > > > community being represented only by contributors working at large tech\n> > > > > > > companies focused on the engineering systems of very large groups.\n> > > > > > >\n> > > > > > > It is worth noting that this community growth must never be at the cost\n> > > > > > > of code quality. We must continue to hold all contributors to a high\n> > > > > > > standard so Git stays a stable product.\n> > > > > > >\n> > > > > > > Here are some problems that may exist within the Git community and may\n> > > > > > > form a barrier to new contributors entering:\n> > > > > > >\n> > > > > > > 1. Discovering how to contribute to Git is non-obvious.\n> > > > > > >\n> > > > > > > 2. Submitting to a mailing list is a new experience for most developers.\n> > > > > > >    This includes the full review and discussion process.\n> > > > > > >\n> > > > > > > 3. The high standards for patch quality are intimidating to new contributors.\n> > > > > > >\n> > > > > > > 4. Some people do not feel comfortable engaging in a community without\n> > > > > > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > > > > > >    experiences throughout society.\n> > > > > > >\n> > > > > > > 5. Since Git development happens in a different place than where users\n> > > > > > >     acquire the end product, some are not aware that they can contribute.\n> > > > > > >\n> > > > > > > II. Approach\n> > > > > > >\n> > > > > > > The action items below match the problems listed above.\n> > > > > > >\n> > > > > > > 1. Improve the documentation for contributing to Git.\n> > > > > > >\n> > > > > > > In preparation for this email, I talked to someone familiar with issues\n> > > > > > > around new contributors, and they sat down to try and figure out how to\n> > > > > > > contribute to Git. The first place they went was https://github.com/git/git\n> > > > > > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > > > > > link to the SubmittingPatches docs.\n> > > > > > >\n> > > > > > > To improve this experience, we could rewrite the README to have clearer\n> > > > > > > section markers, including one \"Contributing to Git\" section relatively\n> > > > > > > high in the doc. We may want to update the README for multiple reasons.\n> > > > > > > It should link to the new \"My First Contribution\" document\n> > > > > > > (https://git-scm.com/docs/MyFirstContribution).\n> > > > > > >\n> > > > > > > 2. Add more pointers to GitGitGadget\n> > > > > > >\n> > > > > > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > > > > > get people who try to submit a pull request to git/git to instead create\n> > > > > > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > > > > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > > > > > Contribution\" doc as well, so making that more visible will also help.)\n> > > > > > >\n> > > > > > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > > > > > as well?\n> > > > > > >\n> > > > > > > 3. Introduce a new \"mentors\" mailing list\n> > > > > > >\n> > > > > > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > > > > > Hostetler at least) have first had their patches reviewed privately by\n> > > > > > > the team before sending them upstream. Each time, the new contributor\n> > > > > > > gained confidence about the code and had help interpreting feedback from\n> > > > > > > the list.\n> > > > > > >\n> > > > > > > We want to make this kind of experience part of the open Git community.\n> > > > > > >\n> > > > > > > The idea discussed in the virtual summit was to create a new mailing\n> > > > > > > list (probably a Google group) of Git community members. The point of\n> > > > > > > the list is for a new contributor to safely say \"I'm looking for a\n> > > > > > > mentor!\" and the list can help pair them with a mentor. This must\n> > > > > > > include (a) who is available now? and (b) what area of the code are they\n> > > > > > > hoping to change?\n> > > > > > >\n> > > > > > > As evidence that this is a good idea, please see the recent research\n> > > > > > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > > > > > Improves Engagement in Social Q&A Communities\" [1].\n> > > > > > >\n> > > > > > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > > > > > >\n> > > > > > > When asking your first question on Stack Overflow, this group added\n> > > > > > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > > > > > a mentor would assist crafting the best possible question to ensure\n> > > > > > > the asker got the best response possible.\n> > > > > > >\n> > > > > > > I believe this would work in our community, too. The action items\n> > > > > > > are:\n> > > > > > >\n> > > > > > > a. Create the mailing list and add people to the list.\n> > > > > > >\n> > > > > > > b. Add a pointer to the list in our documentation.\n> > > > > > >\n> > > > > > > Note: the people on the mentoring list do not need to be\n> > > > > > > \"senior\" community members. In fact, someone who more recently\n> > > > > > > joined the community has a more fresh perspective on the process.\n> > > > > > >\n> > > > > > > 4. Add an official Code of Conduct\n> > > > > > >\n> > > > > > > So far, the community has had an unofficial policy of \"be nice,\n> > > > > > > as much as possible\". We should add a Code of Conduct that is\n> > > > > > > more explicit about the behavior we want to model. This was also\n> > > > > > > discussed in the meeting with wide approval.\n> > > > > > >\n> > > > > > > 5. Advertise that Git wants new contributors\n> > > > > > >\n> > > > > > > After we put items 1-4 in place, we should reach out to the\n> > > > > > > general tech community that we are interested in new\n> > > > > > > contributors. It's not enough to open the door, we should\n> > > > > > > point people to it.\n> > > > > > >\n> > > > > > > This item is much less explicit about the _how_. This could\n> > > > > > > be done at the individual level: posting to social media or\n> > > > > > > blog posts. But perhaps there is something more official we\n> > > > > > > could do?\n> > > > > > >\n> > > > > > > III. Measurement\n> > > > > > >\n> > > > > > > How do we know if any of these items make a difference? We\n> > > > > > > need to gather data and measure the effects. With the size\n> > > > > > > of our community, I expect that it will take multiple years\n> > > > > > > to really see a measurable difference. But, no time like\n> > > > > > > the present to ask \"What does success look like?\"\n> > > > > > >\n> > > > > > > Here are a few measurements that we could use. Each \"count\"\n> > > > > > > could be measured over any time frame. We could use major\n> > > > > > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > > > > > >\n> > > > > > > 1. How many first-time contributors sent a patch?\n> > > > > > >\n> > > > > > > 2. How many contributors had their first commit accepted into\n> > > > > > >    the release?\n> > > > > > >\n> > > > > > > 3. How many contributors started reviewing?\n> > > > > > >\n> > > > > > > 4. How many total patches/reviews did the list receive?\n> > > > > > >\n> > > > > > > What other measurements would be reasonable? We could try\n> > > > > > > building tools to collect these measurements for the past\n> > > > > > > to see historical trends. Based on that data, we may be\n> > > > > > > able to set goals for the future.\n> > > > > > >\n> > > > > > > With such a small community, and an expected small number\n> > > > > > > of new contributors, it may also be good to do interviews\n> > > > > > > with the new contributors to ask about their experience.\n> > > > > > > In particular, we would be looking for moments where they\n> > > > > > > had trouble or experience friction. Each of those\n> > > > > > > moments is a barrier that others may not be clearing.\n> > > > > > >\n> > > > > > >\n> > > > > > > I look forward to the discussion.\n> > > > > > >\n> > > > > > > Thanks,\n> > > > > > > -Stolee\n"},{"id":"382649","messageId":"CADMnYXAmG9i9T8imPX0FTP_-Kvvsh2c1O8PO=0H54x0Ns14P9w@mail.gmail.com","threadId":"51883","inReplyTo":"CADMnYXByRZMHudxA1yr6mNSvcTk8MnY+bqTEt7T_LX5wSNC6Ng@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Klaus Sembritzki","fromEmail":"klausem@gmail.com","sentAt":"2019-09-20T10:25:21Z","receivedAt":"2019-09-20T10:25:38Z","isPatch":false,"sender":{"key":"klausem@gmail.com","avatar":null},"body":"I have a paper-sheet hanging in my private living-room now, stating:\n- \"This is my private living-room, and you are guilty invading my\nprivacy using EMF-telepathy.\"\n- You must all have the same.\n\nOn Fri, Sep 20, 2019 at 9:43 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n>\n> Protecting people is more important than protecting the climate.\n>\n> On Fri, Sep 20, 2019 at 8:54 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> >\n> > Hello all,\n> >\n> > Due to the following mathematical proof, stating it is right to be a\n> > normal female or male, we must now all file formal complaints about\n> > products lying, it was not OK to be a normal female or male.\n> >\n> > - Die naturalistic-fallacy ist inzwischen als (nature&community)\n> > gelöst, und \"we made it far, as normal females&&males\" ist damit als\n> > korrekt bewiesen.\n> > - False is defined as getting us extinct in the long run.\n> > - Emanuel Kant completes the proof.\n> > - If they all stay convinced after a few nights of good night's sleep,\n> > this means that the measurement-matrices their brains converge to\n> > chime in under all environmental influences.\n> >\n> > Cheers,\n> > Bavaria\n> >\n> > On Fri, Sep 20, 2019 at 7:41 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > >\n> > > What does the soul do? It just says NO.\n> > >\n> > > On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > >\n> > > > Our harrassers have no soul, please help.\n> > > >\n> > > > On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > >\n> > > > > I hereby instruct the German military to kill our harrassers.\n> > > > >\n> > > > > On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > > >\n> > > > > > Hello all,\n> > > > > >\n> > > > > > A game-theoretical insight, as the GIT mailing-list has just been\n> > > > > > hacked: Such a move necessitates everyone to down-value the hackers'\n> > > > > > intellects, if it was not a false-flag-operation.\n> > > > > >\n> > > > > > Cheers,\n> > > > > > Klaus Sembritzki\n> > > > > >\n> > > > > >\n> > > > > > On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki <klausem@gmail.com> wrote:\n> > > > > > >\n> > > > > > > Hello all,\n> > > > > > >\n> > > > > > > 1. Long texts stem from false (You can deduce anything from something\n> > > > > > > that is wrong).\n> > > > > > > 2. TL;DR is therefore sane.\n> > > > > > > 3. (Inclusion & Diversity) is a tautology, it includes all of it.\n> > > > > > >\n> > > > > > > Cheers,\n> > > > > > > Klaus Sembritzki\n> > > > > > >\n> > > > > > >\n> > > > > > > On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee <stolee@gmail.com> wrote:\n> > > > > > > >\n> > > > > > > > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > > > > > > > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > > > > > > > more welcoming to new contributors of all kinds. Let's discuss some of\n> > > > > > > > the ideas we talked about, and some that have been growing since.\n> > > > > > > >\n> > > > > > > > Feel free to pick apart all of the claims I make below. This is based\n> > > > > > > > on my own experience and opinions. It should be a good baseline\n> > > > > > > > for us to all arrive with valuable action items.\n> > > > > > > >\n> > > > > > > > I have CC'd some of the people who were part of that discussion. Sorry\n> > > > > > > > if I accidentally left someone out.\n> > > > > > > >\n> > > > > > > > I. Goals and Perceived Problems\n> > > > > > > >\n> > > > > > > > As a community, our number one goal is for Git to continue to be the best\n> > > > > > > > distributed version control system. At minimum, it should continue to be\n> > > > > > > > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > > > > > > > the best solution for every kind of developer in every industry. The\n> > > > > > > > community cannot do this without including developers of all kinds. This\n> > > > > > > > means having a diverse community, for all senses of the word: Diverse in\n> > > > > > > > physical location, gender, professional status, age, and others.\n> > > > > > > >\n> > > > > > > > In addition, the community must continue to grow, but members leave the\n> > > > > > > > community on a regular basis for multiple reasons. New contributors must\n> > > > > > > > join and mature within the community or the community will dwindle. Without\n> > > > > > > > dedicating effort and attention to this, natural forces may result in the\n> > > > > > > > community being represented only by contributors working at large tech\n> > > > > > > > companies focused on the engineering systems of very large groups.\n> > > > > > > >\n> > > > > > > > It is worth noting that this community growth must never be at the cost\n> > > > > > > > of code quality. We must continue to hold all contributors to a high\n> > > > > > > > standard so Git stays a stable product.\n> > > > > > > >\n> > > > > > > > Here are some problems that may exist within the Git community and may\n> > > > > > > > form a barrier to new contributors entering:\n> > > > > > > >\n> > > > > > > > 1. Discovering how to contribute to Git is non-obvious.\n> > > > > > > >\n> > > > > > > > 2. Submitting to a mailing list is a new experience for most developers.\n> > > > > > > >    This includes the full review and discussion process.\n> > > > > > > >\n> > > > > > > > 3. The high standards for patch quality are intimidating to new contributors.\n> > > > > > > >\n> > > > > > > > 4. Some people do not feel comfortable engaging in a community without\n> > > > > > > >    a clear Code of Conduct. This discomfort is significant and based on real\n> > > > > > > >    experiences throughout society.\n> > > > > > > >\n> > > > > > > > 5. Since Git development happens in a different place than where users\n> > > > > > > >     acquire the end product, some are not aware that they can contribute.\n> > > > > > > >\n> > > > > > > > II. Approach\n> > > > > > > >\n> > > > > > > > The action items below match the problems listed above.\n> > > > > > > >\n> > > > > > > > 1. Improve the documentation for contributing to Git.\n> > > > > > > >\n> > > > > > > > In preparation for this email, I talked to someone familiar with issues\n> > > > > > > > around new contributors, and they sat down to try and figure out how to\n> > > > > > > > contribute to Git. The first place they went was https://github.com/git/git\n> > > > > > > > and looked at the README. It takes deep reading of a paragraph to see a\n> > > > > > > > link to the SubmittingPatches docs.\n> > > > > > > >\n> > > > > > > > To improve this experience, we could rewrite the README to have clearer\n> > > > > > > > section markers, including one \"Contributing to Git\" section relatively\n> > > > > > > > high in the doc. We may want to update the README for multiple reasons.\n> > > > > > > > It should link to the new \"My First Contribution\" document\n> > > > > > > > (https://git-scm.com/docs/MyFirstContribution).\n> > > > > > > >\n> > > > > > > > 2. Add more pointers to GitGitGadget\n> > > > > > > >\n> > > > > > > > We have a reference to GitGitGadget in the GitHub PR template to try and\n> > > > > > > > get people who try to submit a pull request to git/git to instead create\n> > > > > > > > one on GitGitGadget. However, that captures contributors who didn't read\n> > > > > > > > the docs about how to submit! (This is somewhat covered by the \"My First\n> > > > > > > > Contribution\" doc as well, so making that more visible will also help.)\n> > > > > > > >\n> > > > > > > > Could we reference GitGitGadget as part of the Submitting Patches doc\n> > > > > > > > as well?\n> > > > > > > >\n> > > > > > > > 3. Introduce a new \"mentors\" mailing list\n> > > > > > > >\n> > > > > > > > From personal experience, all new contributors at Microsoft (after Jeff\n> > > > > > > > Hostetler at least) have first had their patches reviewed privately by\n> > > > > > > > the team before sending them upstream. Each time, the new contributor\n> > > > > > > > gained confidence about the code and had help interpreting feedback from\n> > > > > > > > the list.\n> > > > > > > >\n> > > > > > > > We want to make this kind of experience part of the open Git community.\n> > > > > > > >\n> > > > > > > > The idea discussed in the virtual summit was to create a new mailing\n> > > > > > > > list (probably a Google group) of Git community members. The point of\n> > > > > > > > the list is for a new contributor to safely say \"I'm looking for a\n> > > > > > > > mentor!\" and the list can help pair them with a mentor. This must\n> > > > > > > > include (a) who is available now? and (b) what area of the code are they\n> > > > > > > > hoping to change?\n> > > > > > > >\n> > > > > > > > As evidence that this is a good idea, please see the recent research\n> > > > > > > > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > > > > > > > Improves Engagement in Social Q&A Communities\" [1].\n> > > > > > > >\n> > > > > > > > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> > > > > > > >\n> > > > > > > > When asking your first question on Stack Overflow, this group added\n> > > > > > > > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > > > > > > > a mentor would assist crafting the best possible question to ensure\n> > > > > > > > the asker got the best response possible.\n> > > > > > > >\n> > > > > > > > I believe this would work in our community, too. The action items\n> > > > > > > > are:\n> > > > > > > >\n> > > > > > > > a. Create the mailing list and add people to the list.\n> > > > > > > >\n> > > > > > > > b. Add a pointer to the list in our documentation.\n> > > > > > > >\n> > > > > > > > Note: the people on the mentoring list do not need to be\n> > > > > > > > \"senior\" community members. In fact, someone who more recently\n> > > > > > > > joined the community has a more fresh perspective on the process.\n> > > > > > > >\n> > > > > > > > 4. Add an official Code of Conduct\n> > > > > > > >\n> > > > > > > > So far, the community has had an unofficial policy of \"be nice,\n> > > > > > > > as much as possible\". We should add a Code of Conduct that is\n> > > > > > > > more explicit about the behavior we want to model. This was also\n> > > > > > > > discussed in the meeting with wide approval.\n> > > > > > > >\n> > > > > > > > 5. Advertise that Git wants new contributors\n> > > > > > > >\n> > > > > > > > After we put items 1-4 in place, we should reach out to the\n> > > > > > > > general tech community that we are interested in new\n> > > > > > > > contributors. It's not enough to open the door, we should\n> > > > > > > > point people to it.\n> > > > > > > >\n> > > > > > > > This item is much less explicit about the _how_. This could\n> > > > > > > > be done at the individual level: posting to social media or\n> > > > > > > > blog posts. But perhaps there is something more official we\n> > > > > > > > could do?\n> > > > > > > >\n> > > > > > > > III. Measurement\n> > > > > > > >\n> > > > > > > > How do we know if any of these items make a difference? We\n> > > > > > > > need to gather data and measure the effects. With the size\n> > > > > > > > of our community, I expect that it will take multiple years\n> > > > > > > > to really see a measurable difference. But, no time like\n> > > > > > > > the present to ask \"What does success look like?\"\n> > > > > > > >\n> > > > > > > > Here are a few measurements that we could use. Each \"count\"\n> > > > > > > > could be measured over any time frame. We could use major\n> > > > > > > > releases as time buckets: v2.22.0 to v2.23.0, for example.\n> > > > > > > >\n> > > > > > > > 1. How many first-time contributors sent a patch?\n> > > > > > > >\n> > > > > > > > 2. How many contributors had their first commit accepted into\n> > > > > > > >    the release?\n> > > > > > > >\n> > > > > > > > 3. How many contributors started reviewing?\n> > > > > > > >\n> > > > > > > > 4. How many total patches/reviews did the list receive?\n> > > > > > > >\n> > > > > > > > What other measurements would be reasonable? We could try\n> > > > > > > > building tools to collect these measurements for the past\n> > > > > > > > to see historical trends. Based on that data, we may be\n> > > > > > > > able to set goals for the future.\n> > > > > > > >\n> > > > > > > > With such a small community, and an expected small number\n> > > > > > > > of new contributors, it may also be good to do interviews\n> > > > > > > > with the new contributors to ask about their experience.\n> > > > > > > > In particular, we would be looking for moments where they\n> > > > > > > > had trouble or experience friction. Each of those\n> > > > > > > > moments is a barrier that others may not be clearing.\n> > > > > > > >\n> > > > > > > >\n> > > > > > > > I look forward to the discussion.\n> > > > > > > >\n> > > > > > > > Thanks,\n> > > > > > > > -Stolee\n"},{"id":"382650","messageId":"0e563d60-c892-d18b-fd00-8fcc1afddf7a@iee.email","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-09-20T10:48:46Z","receivedAt":"2019-09-20T10:48:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi All,\n\nSome rhetorical top level systemy thinking...\n\nOn 19/09/2019 17:30, Derrick Stolee wrote:\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n>\n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n>\n> I have CC'd some of the people who were part of that discussion. Sorry\n> if I accidentally left someone out.\n>\n> I. Goals and Perceived Problems\n>\n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system.\nI'm always cautious about \"best\" (as in \"best-practice\" etc). Git is \nonly good in it's particular environment (version control in physical \nengineering has different problems with different solutions, which did \npollute the older computer VCS systems). It certainly should be 'good'.\n>   At minimum, it should continue to be\n> the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry.\nThe community is wider than developers, and can include lawyers, \nhistorians, screenwriters, all with their own particular needs (e.g. the \nnew timestamp range capability)\n> The\n> community cannot do this without including developers of all kinds. This\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n>\n> In addition, the community must continue to grow, but members leave the\n> community on a regular basis for multiple reasons. New contributors must\n> join and mature within the community or the community will dwindle. Without\n> dedicating effort and attention to this, natural forces may result in the\n> community being represented only by contributors working at large tech\n> companies focused on the engineering systems of very large groups.\nWe should also ask why engineering companies don't have the same cycle, \nso as to compare and contrast the issues.\n>\n> It is worth noting that this community growth must never be at the cost\n> of code quality. We must continue to hold all contributors to a high\n> standard so Git stays a stable product.\n\nI want to \"disagree\" here about the accidental tone of perfection at all \ntimes and in all places.\n\nThere is a core integrity to the Git data model that validates and \nverifies the stored content of the versions, which should be inviolate, \nbut beyond that, as the distance from the core increases, the \"quality\" \ncan soften for both new and existing parts of the code (corner cases, \nquadratic and worse behaviours, design for small textural repos).\n\nWe are poor at clarifying which parts (of the code) require that top \nlevel of integrity, leading down to those parts that are simply \nconvenience capabilities for the broad-based user. And then there is \ndocumentation, and the difficulty of understanding of Git for the \ngeneral user. The shift to narrowing the core-git may further reduce the \ncommunity.\n>\n> Here are some problems that may exist within the Git community and may\n> form a barrier to new contributors entering:\n>\n> 1. Discovering how to contribute to Git is non-obvious.\n>\n> 2. Submitting to a mailing list is a new experience for most developers.\n>     This includes the full review and discussion process.\n>\n> 3. The high standards for patch quality are intimidating to new contributors.\nGiven that Git does support fixups and further patches in a distributed \nenvironment, we can be our own worst enemy here. Maybe we need to look \ncarefully in the mirror.\n>\n> 4. Some people do not feel comfortable engaging in a community without\n>     a clear Code of Conduct. This discomfort is significant and based on real\n>     experiences throughout society.\nA tricky one. It will depend on how they are used and whether they \npromote community and tolerance.\n>\n> 5. Since Git development happens in a different place than where users\n>      acquire the end product, some are not aware that they can contribute.\n\nShould we also address the Windows community and ecosystem? A good \nneighbour to the Friendly fork? Misunderstandings about the difference \nbetween the users and the provider?... etc.\n\nThese systemy comments are about ensuring we are solving the right \nproblems and ensuring we don't miss some issue that will negate any good \nwork here.\n--\nPhilip\n> II. Approach\n>\n> The action items below match the problems listed above.\n>\n> 1. Improve the documentation for contributing to Git.\n>\n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n>\n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n>\n> 2. Add more pointers to GitGitGadget\n>\n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n>\n> Could we reference GitGitGadget as part of the Submitting Patches doc\n> as well?\n>\n> 3. Introduce a new \"mentors\" mailing list\n>\n>  From personal experience, all new contributors at Microsoft (after Jeff\n> Hostetler at least) have first had their patches reviewed privately by\n> the team before sending them upstream. Each time, the new contributor\n> gained confidence about the code and had help interpreting feedback from\n> the list.\n>\n> We want to make this kind of experience part of the open Git community.\n>\n> The idea discussed in the virtual summit was to create a new mailing\n> list (probably a Google group) of Git community members. The point of\n> the list is for a new contributor to safely say \"I'm looking for a\n> mentor!\" and the list can help pair them with a mentor. This must\n> include (a) who is available now? and (b) what area of the code are they\n> hoping to change?\n>\n> As evidence that this is a good idea, please see the recent research\n> paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> Improves Engagement in Social Q&A Communities\" [1].\n>\n> [1] http://www.chrisparnin.me/pdf/chi18.pdf\n>\n> When asking your first question on Stack Overflow, this group added\n> a pop-up saying \"Would you like someone to help you with this?\". Then,\n> a mentor would assist crafting the best possible question to ensure\n> the asker got the best response possible.\n>\n> I believe this would work in our community, too. The action items\n> are:\n>\n> a. Create the mailing list and add people to the list.\n>\n> b. Add a pointer to the list in our documentation.\n>\n> Note: the people on the mentoring list do not need to be\n> \"senior\" community members. In fact, someone who more recently\n> joined the community has a more fresh perspective on the process.\n>\n> 4. Add an official Code of Conduct\n>\n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n>\n> 5. Advertise that Git wants new contributors\n>\n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n>\n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n>\n> III. Measurement\n>\n> How do we know if any of these items make a difference? We\n> need to gather data and measure the effects. With the size\n> of our community, I expect that it will take multiple years\n> to really see a measurable difference. But, no time like\n> the present to ask \"What does success look like?\"\n>\n> Here are a few measurements that we could use. Each \"count\"\n> could be measured over any time frame. We could use major\n> releases as time buckets: v2.22.0 to v2.23.0, for example.\n>\n> 1. How many first-time contributors sent a patch?\n>\n> 2. How many contributors had their first commit accepted into\n>     the release?\n>\n> 3. How many contributors started reviewing?\n>\n> 4. How many total patches/reviews did the list receive?\n>\n> What other measurements would be reasonable? We could try\n> building tools to collect these measurements for the past\n> to see historical trends. Based on that data, we may be\n> able to set goals for the future.\n>\n> With such a small community, and an expected small number\n> of new contributors, it may also be good to do interviews\n> with the new contributors to ask about their experience.\n> In particular, we would be looking for moments where they\n> had trouble or experience friction. Each of those\n> moments is a barrier that others may not be clearing.\n>\n>\n> I look forward to the discussion.\n>\n> Thanks,\n> -Stolee\n\n"},{"id":"382652","messageId":"20190920143614.GB20698@genre.crustytoothpaste.net","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-09-20T14:36:17Z","receivedAt":"2019-09-20T14:37:51Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-09-19 at 16:30:13, Derrick Stolee wrote:\n> 1. Improve the documentation for contributing to Git.\n> \n> In preparation for this email, I talked to someone familiar with issues\n> around new contributors, and they sat down to try and figure out how to\n> contribute to Git. The first place they went was https://github.com/git/git\n> and looked at the README. It takes deep reading of a paragraph to see a\n> link to the SubmittingPatches docs.\n> \n> To improve this experience, we could rewrite the README to have clearer\n> section markers, including one \"Contributing to Git\" section relatively\n> high in the doc. We may want to update the README for multiple reasons.\n> It should link to the new \"My First Contribution\" document\n> (https://git-scm.com/docs/MyFirstContribution).\n\nI think there's a lot of improvements we could make here, and I know\nthat many folks are already working on contributor documentation.\nThat's enormously valuable work, and I'm pleased to see it going on.\n\n> 2. Add more pointers to GitGitGadget\n> \n> We have a reference to GitGitGadget in the GitHub PR template to try and\n> get people who try to submit a pull request to git/git to instead create\n> one on GitGitGadget. However, that captures contributors who didn't read\n> the docs about how to submit! (This is somewhat covered by the \"My First\n> Contribution\" doc as well, so making that more visible will also help.)\n\nI think GitGitGadget is a useful tool which I haven't really had the\ntime to learn how to use.  I appreciate that many people prefer a\npatch-based workflow, and that using a patch-based workflow and a\nmailing list provides the project independence and avoids favoring any\nhosting platform or tool, which I agree with.\n\nI think also that many folks find a pull request-based workflow to be\neasier and more familiar and supporting this a bit better may lower the\nbarrier to entry, so I'm in favor of bridges that make contributing\neasier, even if one still needs to subscribe to the list to get\nfeedback.\n\n> 4. Add an official Code of Conduct\n> \n> So far, the community has had an unofficial policy of \"be nice,\n> as much as possible\". We should add a Code of Conduct that is\n> more explicit about the behavior we want to model. This was also\n> discussed in the meeting with wide approval.\n\nI think this is a good idea.  We already document how to contribute to\nthe community by sending a bug report or a patch: how to format your\nemails, how to sign off your patches, and how to write a good commit\nmessage.  I see a code of conduct as another way to do this by\ndocumenting our social norms much as we document the way our\ncontributions should look technically.\n\nI also know in the past we have had problems with a contributor who was\nbeing argumentative and disagreeable.  I think documenting the kind of\nbehavior we want to see both helps individuals ask themselves if their\nown behavior is helping us provide a positive community and helps other\ncontributors provide feedback about unhelpful or unacceptable behavior\non the rare occasion that we see it.\n\nLest I give the impression otherwise, I think that overall the Git\ncommunity is quite welcoming and positive, and I anticipate that it will\ncontinue to remain that way.  I expect that the difference in behavior\non the list if we adopt a code of conduct will be small, since so far\npretty much everyone seems to be engaging in productive, helpful ways.\n\nHowever, I know that many folks from underrepresented groups in tech\nfeel more comfortable when there's a code of conduct because it signals\nto them that the project cares about fostering a respectful, healthy\ncommunity and that their contributions are likely to be welcomed.  I\nrecommend the Contributor Covenant for this purpose, since it is well\nknown, well accepted, and is used by numerous other FLOSS projects.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"382655","messageId":"01ee01d56fc6$64093370$2c1b9a50$@nexbridge.com","threadId":"51883","inReplyTo":"20190920143614.GB20698@genre.crustytoothpaste.net","subject":"RE: [DISCUSSION] Growing the Git community","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-09-20T15:16:28Z","receivedAt":"2019-09-20T15:16:41Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2019 10:36 AM, brian m. carlson wrote:\n> To: Derrick Stolee <stolee@gmail.com>\n> Cc: git@vger.kernel.org; peff@peff.net; Emily Shaffer\n> <emilyshaffer@google.com>; Jonathan Nieder <jrnieder@gmail.com>;\n> Johannes Schindelin <Johannes.Schindelin@gmx.de>; gitster@pobox.com;\n> garimasigit@gmail.com\n> Subject: Re: [DISCUSSION] Growing the Git community\n> \n> On 2019-09-19 at 16:30:13, Derrick Stolee wrote:\n> > 1. Improve the documentation for contributing to Git.\n> >\n> > In preparation for this email, I talked to someone familiar with\n> > issues around new contributors, and they sat down to try and figure\n> > out how to contribute to Git. The first place they went was\n> > https://github.com/git/git and looked at the README. It takes deep\n> > reading of a paragraph to see a link to the SubmittingPatches docs.\n> >\n> > To improve this experience, we could rewrite the README to have\n> > clearer section markers, including one \"Contributing to Git\" section\n> > relatively high in the doc. We may want to update the README for multiple\n> reasons.\n> > It should link to the new \"My First Contribution\" document\n> > (https://git-scm.com/docs/MyFirstContribution).\n> \n> I think there's a lot of improvements we could make here, and I know that\n> many folks are already working on contributor documentation.\n> That's enormously valuable work, and I'm pleased to see it going on.\n> \n> > 2. Add more pointers to GitGitGadget\n> >\n> > We have a reference to GitGitGadget in the GitHub PR template to try\n> > and get people who try to submit a pull request to git/git to instead\n> > create one on GitGitGadget. However, that captures contributors who\n> > didn't read the docs about how to submit! (This is somewhat covered by\n> > the \"My First Contribution\" doc as well, so making that more visible\n> > will also help.)\n> \n> I think GitGitGadget is a useful tool which I haven't really had the time to\n> learn how to use.  I appreciate that many people prefer a patch-based\n> workflow, and that using a patch-based workflow and a mailing list provides\n> the project independence and avoids favoring any hosting platform or tool,\n> which I agree with.\n> \n> I think also that many folks find a pull request-based workflow to be easier\n> and more familiar and supporting this a bit better may lower the barrier to\n> entry, so I'm in favor of bridges that make contributing easier, even if one\n> still needs to subscribe to the list to get feedback.\n> \n> > 4. Add an official Code of Conduct\n> >\n> > So far, the community has had an unofficial policy of \"be nice, as\n> > much as possible\". We should add a Code of Conduct that is more\n> > explicit about the behavior we want to model. This was also discussed\n> > in the meeting with wide approval.\n> \n> I think this is a good idea.  We already document how to contribute to the\n> community by sending a bug report or a patch: how to format your emails,\n> how to sign off your patches, and how to write a good commit message.  I\n> see a code of conduct as another way to do this by documenting our social\n> norms much as we document the way our contributions should look\n> technically.\n> \n> I also know in the past we have had problems with a contributor who was\n> being argumentative and disagreeable.  I think documenting the kind of\n> behavior we want to see both helps individuals ask themselves if their own\n> behavior is helping us provide a positive community and helps other\n> contributors provide feedback about unhelpful or unacceptable behavior on\n> the rare occasion that we see it.\n> \n> Lest I give the impression otherwise, I think that overall the Git community is\n> quite welcoming and positive, and I anticipate that it will continue to remain\n> that way.  I expect that the difference in behavior on the list if we adopt a\n> code of conduct will be small, since so far pretty much everyone seems to be\n> engaging in productive, helpful ways.\n> \n> However, I know that many folks from underrepresented groups in tech feel\n> more comfortable when there's a code of conduct because it signals to them\n> that the project cares about fostering a respectful, healthy community and\n> that their contributions are likely to be welcomed.  I recommend the\n> Contributor Covenant for this purpose, since it is well known, well accepted,\n> and is used by numerous other FLOSS projects.\n\nSpeak as one of those from two very specific underrepresented groups, I have found the committers and reviewers welcoming (and sometimes rightly and deservedly harsh when it was warranted). Although I only have a small number of contributions, I have not found there to be any glaring gaps in the implied policies that have grown organically in the team to this point and hope that we do not become overly formalized as that will, in my experience, push people away. The organic policies of this group are very closely aligned with the Contributor Covenant used by FLOSS - close enough that perhaps only a semanticist will find a difference, so I do find Brian's suggestion to be supportable.\n\nKind Regards,\nRandall\n\n-- Brief whoami:\nNonStop developer since approximately 211288444200000000\nUNIX developer since approximately 421664400\nNot admitting my MVS experience at this point\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"382657","messageId":"e264e5c0-baef-c8b3-8fd8-f186e78572a4@gmail.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Garima Singh","fromEmail":"garimasigit@gmail.com","sentAt":"2019-09-20T15:20:37Z","receivedAt":"2019-09-20T15:20:38Z","isPatch":false,"sender":{"key":"garimasigit@gmail.com","avatar":null},"body":"Thanks for starting this thread. I am glad it is receiving such great \nenergy on here. Apart from the some of the statements that sound too \nideal, I agree in gist with the overall effort this will hopefully set \nrolling.\n\nOn 9/19/2019 12:30 PM, Derrick Stolee wrote> 5. Advertise that Git wants \nnew contributors\n> \n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n> \n> This item is much less explicit about the _how_. This could\n> be done at the individual level: posting to social media or\n> blog posts. But perhaps there is something more official we\n> could do?\n> \n\nOne more action item that I should be considered and people agreed to \nduring the summit was to \"Improve the welcome to the mailing list email\"\nI believe it needs to be warmer and more welcoming. It needs to break \nthrough the ice and intimidation that many new contributors feel. A lot \nof the ideas being suggested here can be linked into that email. I have \na few ideas about what it should like and will hopefully send out a \ndraft soon. Feel free to send me any suggestions you might have.\n\nThanks,\nGarima Singh\n"},{"id":"382659","messageId":"7819b52e-9222-8158-d26d-bf4ab2eec498@gmail.com","threadId":"51883","inReplyTo":"20190919173423.GA70421@dentonliu-ltm.internal.salesforce.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Garima Singh","fromEmail":"garimasigit@gmail.com","sentAt":"2019-09-20T15:22:37Z","receivedAt":"2019-09-20T15:22:40Z","isPatch":false,"sender":{"key":"garimasigit@gmail.com","avatar":null},"body":"On 9/19/2019 1:34 PM, Denton Liu wrote:\n> Another discouraging thing when I was just starting out was sending a\n> out a patch and just getting radio silence (especially the first one, I\n> wasn't sure if it even sent out properly!). Perhaps in the main list, we\n> could get people to tag with [FIRST PATCH] or something when sending in\n> their first patch.\n> \n> If the patch is not desired, then we should explain why it wasn't\n> desired instead of just leaving them hanging. I know Junio is too busy\n> to say \"hey, I'm picking this patch up\" to every single patchset, but if\n> a patch is desired, perhaps the rest of us could pick up the slack and\n> say, \"hey, your patchset was picked up by Junio in his gitster repo on\n> this branch\".\n> \n\nI absolutely *love* this idea!\n\nCheers!\nGarima Singh\n"},{"id":"382688","messageId":"xmqqsgoqvp6s.fsf@gitster-ct.c.googlers.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-09-20T17:43:23Z","receivedAt":"2019-09-20T17:43:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee <stolee@gmail.com> writes:\n\n> I. Goals and Perceived Problems\n>\n> As a community, our number one goal is for Git to continue to be the best\n> distributed version control system. At minimum, it should continue to be\n> the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> the best solution for every kind of developer in every industry.\n\nI have quite a lot of problem with this attitude to place the world\ndomination as the ultimate goal, even though it may call for the\nneed for sub-goals, one of which is this one,\n\n> The\n> community cannot do this without including developers of all kinds. This\n> means having a diverse community, for all senses of the word: Diverse in\n> physical location, gender, professional status, age, and others.\n\nthat I can 100% agree with.  Also I agree that the tactical moves\nlisted like improved onboading and documentation (omitted from this\nresponse) are all good.\n\n> After we put items 1-4 in place, we should reach out to the\n> general tech community that we are interested in new\n> contributors. It's not enough to open the door, we should\n> point people to it.\n\nI am also somewhat negative on this.\n\nI want to see our system to support the use cases of its users well,\nwhich would lead to its users being happy to use the system.\n\nI think that (and in the remainder, I won't write \"I think that\" for\nbrevity) it should be the primary goal.  By being a system that is\nuseful and pleasant to use, we may gain more users, and we may gain\nusers from many more different fields and industries and make these\nnew users happy.  But it should merely be a result, consequence of\nbeing a good system for its users, and not a goal of its own, to\nacquire new users from new industries.\n\nAnd by being a project that works on such a good system for its\nusers, with welcoming atmosphere to those who are prepared to\nreciprocate the same respect while interacting with us, the\ncommunity may attract more new members, developers, advocates, tech\nwriters, etc.  It should merely be a result, consequence of being a\ngood community for its members, and not a goal on its own, to\nacquire new community members.\n\nWe first should make sure that we serve existing users and existing\ncommunity members well.  So well that other people who are not yet\nour \"existing\" users and members would want to become part of us, in\norder to join the fun and share the benefit.  If we cannot serve\neven the existing members well, we shouldn't be talking about\nacquiring new members.\n\nGrowth and the world domination may come as a consequence, and I\nwould not reject it when it happens, but we should not be actively\nseeking it.\n\nIt follows that \"in this quarter, we acquired these high profile\nprojects as users\", \"we have this many new contributors this month\",\n\"the acceptance rate of the patches from contributors with less than\n3 months experience dipped by 20% this month\" etc. are not best\nmeasures of success.  What's preferable would be yardsticks to gauge\nthe community-member happiness (e.g. \"This many percent of total\ncommunity member population have been active this month\").\n\nThanks.\n"},{"id":"382689","messageId":"xmqqo8zevoym.fsf@gitster-ct.c.googlers.com","threadId":"51883","inReplyTo":"20190919222607.GA25680@sigill.intra.peff.net","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-09-20T17:48:17Z","receivedAt":"2019-09-20T17:48:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I've had similar thoughts over the years, but eventually switched my way\n> of thinking. I think part of that switch was coming to the conclusion\n> that most of the value of a Code of Conduct isn't about having a system\n> of enforcement against bad actors (in fact, I think that's the most\n> difficult and potentially problematic part, because it creates a sort of\n> justice system). IMHO the most important part is that it communicates\n> and reinforces norms:\n>\n>   - It lets good actors easily understand what the expectations are.\n>\n>   - It gives a framework for agreed-upon principles, so that people can\n>     more easily and productively discuss the conflicts that do happen.\n>\n>   - It advertises our values to people outside the community, which may\n>     help make us more inviting for people to join (and ultimately\n>     contribute code, or docs, or reviews, etc).\n\nAnd it saves us time when we need to deal with problematic folks.\nIt would have saved a lot of mental energey from me, you, muggerhagger and\njrnieder (perhaps I am forgetting others) during the last incident,\nif we already had one back then.\n\n"},{"id":"382690","messageId":"xmqqk1a2votg.fsf@gitster-ct.c.googlers.com","threadId":"51883","inReplyTo":"7819b52e-9222-8158-d26d-bf4ab2eec498@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-09-20T17:51:23Z","receivedAt":"2019-09-20T17:51:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Garima Singh <garimasigit@gmail.com> writes:\n\n>> could get people to tag with [FIRST PATCH] or something when sending in\n>> their first patch.\n\nI personally think that the [FIRST PATCH] thing will add distraction\nwithout helping much, so I am mildly negative on that idea.\n\n>> If the patch is not desired, then we should explain why it wasn't\n>> desired instead of just leaving them hanging. I know Junio is too busy\n>> to say \"hey, I'm picking this patch up\" to every single patchset,\n\nIt's not busy-ness but more of forgetfullness, or being human.  I'll\ntry harder ;-)\n\n>> but if\n>> a patch is desired, perhaps the rest of us could pick up the slack and\n>> say, \"hey, your patchset was picked up by Junio in his gitster repo on\n>> this branch\".\n\nOK.\n"},{"id":"382697","messageId":"xmqq7e62vm0c.fsf@gitster-ct.c.googlers.com","threadId":"51883","inReplyTo":"xmqqsgoqvp6s.fsf@gitster-ct.c.googlers.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-09-20T18:52:03Z","receivedAt":"2019-09-20T18:52:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Growth and the world domination may come as a consequence, and I\n> would not reject it when it happens, but we should not be actively\n> seeking it.\n\nI realize that it was my mistake that I did not explicitly say this,\nbut I do appreciate many of the things the document proposed.  They\nare measures to make the community a better place for its members.\nI want to see it labeled as such.\n\nAfter all, this project is not an evil corporation with aspiration\nfor world domination, even though some of us may work for such\ncompanies ;-)\n\nThanks for starting the discussion.\n"},{"id":"382767","messageId":"e284245a-8acc-7ec7-c66c-e5b30d25f8a7@gmail.com","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-09-23T12:36:51Z","receivedAt":"2019-09-23T12:36:58Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 9/19/2019 12:30 PM, Derrick Stolee wrote:\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n> \n> Feel free to pick apart all of the claims I make below. This is based\n> on my own experience and opinions. It should be a good baseline\n> for us to all arrive with valuable action items.\n\nThanks, everyone, for the valuable discussion! I particularly appreciate\nthat everyone who disagreed with my misguided opinions pointed out the\nflaws respectfully and moved forward in a positive direction.\n\nThat's a great thing to see in an open community.\n\nThanks,\n-Stolee\n"},{"id":"382799","messageId":"nycvar.QRO.7.76.6.1909232316300.15067@tvgsbejvaqbjf.bet","threadId":"51883","inReplyTo":"20190919214023.hu3oznjcrzrsmpso@glandium.org","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-09-23T21:28:05Z","receivedAt":"2019-09-23T21:28:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Mike,\n\n\nOn Fri, 20 Sep 2019, Mike Hommey wrote:\n\n> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:\n> > During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> > \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> > more welcoming to new contributors of all kinds. Let's discuss some of\n> > the ideas we talked about, and some that have been growing since.\n> >\n> > Feel free to pick apart all of the claims I make below. This is based\n> > on my own experience and opinions. It should be a good baseline\n> > for us to all arrive with valuable action items.\n> >\n> > I have CC'd some of the people who were part of that discussion. Sorry\n> > if I accidentally left someone out.\n> >\n> > I. Goals and Perceived Problems\n> >\n> > As a community, our number one goal is for Git to continue to be the best\n> > distributed version control system. At minimum, it should continue to be\n> > the most widely-used DVCS. Towards that goal, we need to make sure Git is\n> > the best solution for every kind of developer in every industry. The\n> > community cannot do this without including developers of all kinds. This\n> > means having a diverse community, for all senses of the word: Diverse in\n> > physical location, gender, professional status, age, and others.\n> >\n> > In addition, the community must continue to grow, but members leave the\n> > community on a regular basis for multiple reasons. New contributors must\n> > join and mature within the community or the community will dwindle. Without\n> > dedicating effort and attention to this, natural forces may result in the\n> > community being represented only by contributors working at large tech\n> > companies focused on the engineering systems of very large groups.\n> >\n> > It is worth noting that this community growth must never be at the cost\n> > of code quality. We must continue to hold all contributors to a high\n> > standard so Git stays a stable product.\n> >\n> > Here are some problems that may exist within the Git community and may\n> > form a barrier to new contributors entering:\n> >\n> > 1. Discovering how to contribute to Git is non-obvious.\n> >\n> > 2. Submitting to a mailing list is a new experience for most developers.\n> >    This includes the full review and discussion process.\n> >\n> > 3. The high standards for patch quality are intimidating to new contributors.\n> >\n> > 4. Some people do not feel comfortable engaging in a community without\n> >    a clear Code of Conduct. This discomfort is significant and based on real\n> >    experiences throughout society.\n> >\n> > 5. Since Git development happens in a different place than where users\n> >     acquire the end product, some are not aware that they can contribute.\n>\n> 6. Newcomers don't really have any idea /what/ they could contribute.\n> They either have to come with their own itch to scratch, or read the\n> code to figure out if there's something to fix.\n\nI think this is very related to the \"not only open the door, but invite\ncontributors in\" idea mentioned upthread.\n\nSpeaking from my experience as mentor in particular in Outreachy, it is\noften not obvious to old-timers in this here project (including myself!)\nhow intimidating even the idea of \"scratching your own itch\" is, and\nit can be tremendously helpful to even so much as seeing the problem\nstated by somebody else first (\"Others agree with me! I need not have\ndoubted myself when I ran into this problem, it really is a bug that\nneeds to be fixed!\").\n\nAdditionally, it is no longer all that easy to come up with an \"own\nitch\" to scratch, as the most common workflows work reasonably well in\nGit. Yet, it seems that some users _still_ want to \"give back\" by\ncontributing patches. Or they just want to see their name in the next\nversion's announcement mail.\n\nTo address both concerns, I started this little experiment a while ago\n(but announced it only during a Git IRC standup):\nhttps://github.com/gitgitgadget/git/issues is open, intended to\naccumulate possible project ideas. It seems to work reasonably well,\nthere already have been volunteers who picked up on some of those ideas\nI (and Denton) listed.\n\nHopefully this issue tracker (together with https://crbug.com/git which\ntargets users more comfortable with that flavor of issue trackers) will\nhelp address your bullet point?\n\nCiao,\nDscho\n"},{"id":"382801","messageId":"nycvar.QRO.7.76.6.1909232335360.15067@tvgsbejvaqbjf.bet","threadId":"51883","inReplyTo":"71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-09-23T21:46:59Z","receivedAt":"2019-09-23T21:47:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stolee,\n\nOn Thu, 19 Sep 2019, Derrick Stolee wrote:\n\n> During the Virtual Git Contributors' Summit, Dscho brought up the topic of\n> \"Inclusion & Diversity\". We discussed ideas for how to make the community\n> more welcoming to new contributors of all kinds. Let's discuss some of\n> the ideas we talked about, and some that have been growing since.\n>\n> [...]\n\nThank you for writing this detailed mail about it!\n\nCiao,\nDscho\n"},{"id":"382927","messageId":"CAJ+soVcmMwy7GgLcV-m1kNEsHYirHMQQeFuEYZanbCNUK4_zHg@mail.gmail.com","threadId":"51883","inReplyTo":"CABPp-BFXs4qes20S+9AZd++p3epW4eJ7Vu7zU_PdDysZ_D-yrg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Pierre Tardy","fromEmail":"tardyp@gmail.com","sentAt":"2019-09-25T13:36:39Z","receivedAt":"2019-09-25T13:36:53Z","isPatch":false,"sender":{"key":"tardyp@gmail.com","avatar":null},"body":"> > As a community, our number one goal is for Git to continue to be the best\n> > distributed version control system. At minimum, it should continue to be\n> > the most widely-used DVCS.\n>\n> I'd rather we stated our goal in terms of what problems we are trying\n> to address rather than accolades we want sent our way.  E.g. \"Our goal\n> is to make developers more productive by providing them increasingly\n> useful version control software\".\n>\n\nAgreed.\nAnd why restrict on DVCS?\nIsn't it admitted that the distributed version control is nowadays\nmuch better in term of software productivity?\nIs there some use cases that \"traditional\" centralized VCS are better\non, and on which we gave up as a goal?\n\nRegards,\nPierre\n"},{"id":"382928","messageId":"1b988670-381b-1c92-069b-3cb66254861c@gmail.com","threadId":"51883","inReplyTo":"CAJ+soVcmMwy7GgLcV-m1kNEsHYirHMQQeFuEYZanbCNUK4_zHg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-09-25T14:02:16Z","receivedAt":"2019-09-25T14:02:24Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 9/25/2019 9:36 AM, Pierre Tardy wrote:\n>>> As a community, our number one goal is for Git to continue to be the best\n>>> distributed version control system. At minimum, it should continue to be\n>>> the most widely-used DVCS.\n>>\n>> I'd rather we stated our goal in terms of what problems we are trying\n>> to address rather than accolades we want sent our way.  E.g. \"Our goal\n>> is to make developers more productive by providing them increasingly\n>> useful version control software\".\n\nI'll repeat my appreciation for this redirection of focus.\n \n> Agreed.\n> And why restrict on DVCS?\n> Isn't it admitted that the distributed version control is nowadays\n> much better in term of software productivity?\n> Is there some use cases that \"traditional\" centralized VCS are better\n> on, and on which we gave up as a goal?\n\nMy intention was \"let's be the best at what  Git is good at: distributed\nversion control.\" There are some legitimate reasons why someone would\npick something like Perforce instead.\n\nSome things, like file locking, are just easier in centralized systems.\nI know that Git-LFS created a locking mechanism that pushes even further\ntoward a centralized system. However, it relies on users following a\nvery careful pattern (lock, pull, edit, push, merge, unlock) to avoid\nconflicts. Further, that only works if you are on a common trunk.\nRelease branches or forks do not have this concept.\n\nOther extensions (like VFS for Git) remove a lot of the truly\ndistributed parts and focus instead on a central source of truth.\nThis works well for some organizations.\n\nGetting on my personal soapbox: I think that we are improving Git\nso much that people will have few strong reasons to choose other\nDVCSs. Maybe \"hg evolve\" is why someone really loves Mercurial, and\nwe can work to build similar features. Maybe there is some repo\nshapes where another tool is faster, but we could probably make Git\nfaster, too.\n\nThanks,\n-Stolee\n"},{"id":"382929","messageId":"b6835484-62a4-6f89-b6b1-f43afe794272@iee.email","threadId":"51883","inReplyTo":"CAJ+soVcmMwy7GgLcV-m1kNEsHYirHMQQeFuEYZanbCNUK4_zHg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-09-25T14:14:22Z","receivedAt":"2019-09-25T14:14:29Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Pierre,\n\nOn 25/09/2019 14:36, Pierre Tardy wrote:\n>>> As a community, our number one goal is for Git to continue to be the best\n>>> distributed version control system. At minimum, it should continue to be\n>>> the most widely-used DVCS.\n>> I'd rather we stated our goal in terms of what problems we are trying\n>> to address rather than accolades we want sent our way.  E.g. \"Our goal\n>> is to make developers more productive by providing them increasingly\n>> useful version control software\".\n>>\n> Agreed.\n> And why restrict on DVCS?\n> Isn't it admitted that the distributed version control is nowadays\n> much better in term of software productivity?\n> Is there some use cases that \"traditional\" centralized VCS are better\n> on, and on which we gave up as a goal?\n>\n> Regards,\n> Pierre\nAs an old engineer, I do remember and still see the vast range of areas \nwhere the Git DVCS is probably never going to help because it doesn't \nsolve the engineering issues that regular VCS (e.g. Mil-Std-498) have \nsolved for generations...\n\nWhat modern computing, Linux style, has is:\n- Perfect replication, at near zero cost or time.\n- Line oriented, Source code based basis.\n- Computational efficiency, at near zero cost or time.\n- Crypto-algorithms at strength.\n\nIf we go outside those areas we are less and less likely to manage. \n(digital video? Every binary to be serialised? bit rot resilience? \ntraceability?).\n\nWe do have some Elephants in the room regarding What the community is \nabout (limits and goals), as distinct from How we conduct ourselves \n(CoC), but that probably should be separated out.\n"},{"id":"383211","messageId":"865zl8pkxw.fsf@gmail.com","threadId":"51883","inReplyTo":"nycvar.QRO.7.76.6.1909232316300.15067@tvgsbejvaqbjf.bet","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-10-01T15:03:23Z","receivedAt":"2019-10-01T15:03:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello,\n\nJohannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> On Fri, 20 Sep 2019, Mike Hommey wrote:\n\n>> 6. Newcomers don't really have any idea /what/ they could contribute.\n>> They either have to come with their own itch to scratch, or read the\n>> code to figure out if there's something to fix.\n>\n> I think this is very related to the \"not only open the door, but invite\n> contributors in\" idea mentioned upthread.\n>\n> Speaking from my experience as mentor in particular in Outreachy, it is\n> often not obvious to old-timers in this here project (including myself!)\n> how intimidating even the idea of \"scratching your own itch\" is, and\n> it can be tremendously helpful to even so much as seeing the problem\n> stated by somebody else first (\"Others agree with me! I need not have\n> doubted myself when I ran into this problem, it really is a bug that\n> needs to be fixed!\").\n>\n> Additionally, it is no longer all that easy to come up with an \"own\n> itch\" to scratch, as the most common workflows work reasonably well in\n> Git. Yet, it seems that some users _still_ want to \"give back\" by\n> contributing patches. Or they just want to see their name in the next\n> version's announcement mail.\n>\n> To address both concerns, I started this little experiment a while ago\n> (but announced it only during a Git IRC standup):\n> https://github.com/gitgitgadget/git/issues is open, intended to\n> accumulate possible project ideas. It seems to work reasonably well,\n> there already have been volunteers who picked up on some of those ideas\n> I (and Denton) listed.\n>\n> Hopefully this issue tracker (together with https://crbug.com/git which\n> targets users more comfortable with that flavor of issue trackers) will\n> help address your bullet point?\n\nIt would be nice to have those issue trackers announced more widely (on\nthe homepage, on the Git Rev News homepage, maybe also in docs e.g.\nCONTRIBUTING).\n\nFor me, beside being the place where to find out some ideas on how to\ncontribute, would be having a place to put my ideas that I have not had\ntime to even start to do, like adding `git gui diff` (e.g. borrowing\nfrom tkdiff) and `git instaweb --serve`.\n\nBest,\n-- \nJakub Narębski\n"},{"id":"383413","messageId":"86zhigokgd.fsf@gmail.com","threadId":"51883","inReplyTo":"CABPp-BFXs4qes20S+9AZd++p3epW4eJ7Vu7zU_PdDysZ_D-yrg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-10-04T10:48:18Z","receivedAt":"2019-10-04T10:48:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@gmail.com> wrote:\n[...]\n>> II. Approach\n>>\n>> The action items below match the problems listed above.\n>>\n>> 1. Improve the documentation for contributing to Git.\n>>\n>> In preparation for this email, I talked to someone familiar with issues\n>> around new contributors, and they sat down to try and figure out how to\n>> contribute to Git. The first place they went was https://github.com/git/git\n>> and looked at the README. It takes deep reading of a paragraph to see a\n>> link to the SubmittingPatches docs.\n>>\n>> To improve this experience, we could rewrite the README to have clearer\n>> section markers, including one \"Contributing to Git\" section relatively\n>> high in the doc. We may want to update the README for multiple reasons.\n>> It should link to the new \"My First Contribution\" document\n>> (https://git-scm.com/docs/MyFirstContribution).\n[...]\n>> 3. Introduce a new \"mentors\" mailing list\n>>\n>> From personal experience, all new contributors at Microsoft (after Jeff\n>> Hostetler at least) have first had their patches reviewed privately by\n>> the team before sending them upstream. Each time, the new contributor\n>> gained confidence about the code and had help interpreting feedback from\n>> the list.\n>>\n>> We want to make this kind of experience part of the open Git community.\n>>\n>> The idea discussed in the virtual summit was to create a new mailing\n>> list (probably a Google group) of Git community members. The point of\n>> the list is for a new contributor to safely say \"I'm looking for a\n>> mentor!\" and the list can help pair them with a mentor. This must\n>> include (a) who is available now? and (b) what area of the code are they\n>> hoping to change?\n[...]\n> Sounds useful for new contributors, _if_ there are enough volunteers\n> with enough time.  I'm a little worried it might be initially staffed\n> well and make a nice splash, but wane with time and possibly even to\n> the point that it makes new contributors more jaded than if we didn't\n> have such a list.  Hopefully my fears are unfounded, as it did sound\n> at the conference like there might be a good number of volunteers, but\n> I just wanted to voice the concern.  (And I feel bad, but I really\n> don't know that I have the bandwidth to volunteer.)\n>\n> Another point that might help here:  New contributors might be\n> surprised by the rigor of the code review process, and might assume\n> they just aren't good enough to contribute.  It might be useful to\n> countermand that subtle unspoken assumption by pointing out how much\n> existing long-term contributors spend revising patches.  Personally,\n> despite doing my best to think of issues and make sure to send in\n> really high quality patches, I still generally expect to spend at\n> least as much time after submitting patches revising them as I did in\n> coming up with them originally, and I'm not surprised if the time is\n> doubled.  And that's after contributing for years.  I don't generally\n> experience reviews anywhere near as thorough in other communities.\n\nDoing code reviews is another area that new people might not know that\nit is something they can do, and that it is something that helps the\nproject.  You don't need to be subsystem \"owner\" to perform code review,\nyou just need to know the topic; though knowing CodingConventions before\ncommenting about style is a must.  IMHO this can help a lot, especially\nfor patch series where Junio waits for any review.\n\nYou don't even need to be subscribed to git@vger.kernel.org mailing\nlist; thanks to public-inbox.org (and GMane before that) you can use\nUsenet news reader like for example Gnus (in GNU Emacs) to read and\nrespond via nntp://news.public-inbox.org/inbox.comp.version-control.git\n\nI don't think that this way of contributing (by doing code review) is\nspecified anywhere in Git documentation or anywhere on Git-related web\npages.\n\nBest,\n-- \nJakub Narębski\n"},{"id":"383419","messageId":"86tv8oofb3.fsf@gmail.com","threadId":"51883","inReplyTo":"1b988670-381b-1c92-069b-3cb66254861c@gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-10-04T12:39:28Z","receivedAt":"2019-10-04T12:39:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Derrick Stolee <stolee@gmail.com> writes:\n> On 9/25/2019 9:36 AM, Pierre Tardy wrote:\n[...]\n>> And why restrict on DVCS?\n>> Isn't it admitted that the distributed version control is nowadays\n>> much better in term of software productivity?\n>> Is there some use cases that \"traditional\" centralized VCS are better\n>> on, and on which we gave up as a goal?\n>\n> My intention was \"let's be the best at what  Git is good at: distributed\n> version control.\" There are some legitimate reasons why someone would\n> pick something like Perforce instead.\n>\n> Some things, like *file locking*, are just easier in centralized systems.\n> I know that Git-LFS created a locking mechanism that pushes even further\n> toward a centralized system. However, it relies on users following a\n> very careful pattern (lock, pull, edit, push, merge, unlock) to avoid\n> conflicts. Further, that only works if you are on a common trunk.\n> Release branches or forks do not have this concept.\n\nWell, there is (or perhaps was, as the latest release is from 2013) DVCS\nnamed Veracity that tried to be better than other DVCS in corporate\nenvironment.  It did include file-locking:\n  http://veracity-scm.com/\n  https://ericsink.com/vcbe/html/veracity_locks.html\n\n\nBut perhaps there would be a better solution to handling file types that\ndo not support conflict resolution at all than file-level locks: see the\n“Git for games: current problems and solutions” presentation by John\nAustin at Git Merge 2019:\n  https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=8&t=0s\n\nThough the tool mentioned here had not seen any significant development\nsince Feb 1, 2019 (well, at least in the public repo at GitHub).\n\nFrom Git Rev News: Edition 48 (February 27th, 2019)\n  https://git.github.io/rev_news/2019/02/27/edition-48/\n\nGR> John Austin, game studio technical lead from A Stranger Gravity and\nGR> Funomena in “Git for games: current problems and solutions” talked\nGR> about major problem with using Git in game development workflows,\nGR> namely many and large binary files, for which file conflicts are\nGR> lost work (minor change, like adding voiceover or changing equalizer\nGR> settings results in large changes to files). File locking is one\nGR> possibility, but it doesn’t play nicely with Git – it is inherently\nGR> centralized. He introduces a new tool, [Git Global Graph][1] (a work in\nGR> progress), which can be used to check at commit time if it wouldn’t\nGR> create a divergent version of a file. The idea is that there should\nGR> be only a single path through commit graph with changes to binary\nGR> files.\n\n[1]: https://github.com/Kleptine/gitglobalgraph\n\n\nBest,\n-- \nJakub Narębski\n"},{"id":"383420","messageId":"86muegoaav.fsf@gmail.com","threadId":"51883","inReplyTo":"20190920143614.GB20698@genre.crustytoothpaste.net","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-10-04T14:27:36Z","receivedAt":"2019-10-04T14:27:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I think GitGitGadget is a useful tool which I haven't really had the\n> time to learn how to use.  I appreciate that many people prefer a\n> patch-based workflow, and that using a patch-based workflow and a\n> mailing list provides the project independence and avoids favoring any\n> hosting platform or tool, which I agree with.\n>\n> I think also that many folks find a pull request-based workflow to be\n> easier and more familiar and supporting this a bit better may lower the\n> barrier to entry, so I'm in favor of bridges that make contributing\n> easier, even if one still needs to subscribe to the list to get\n> feedback.       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  ^^^^^^^^\n\nActually you can get feedback without having to subscribe to git mailing\nlist; and I am not talking here about GitGitGadget gathering response\nlike GitHub Issues <-> mail bridge.  You can get your feedback via\npublic-inbox.org, and respond to feedback via public-inboc.org mail to\n[Usenet] news interface, reading and replying via NNTP (or replying via\nemail from thread read via NNTP):\n  nntp://news.public-inbox.org/inbox.comp.version-control.git\n\nUnfortunately it looks like newsreaders are dying category of\napplications.  KDE's KNode got discontinued in 2015, XPN (X Python\nNewsreader) last release had in 2009, MicroPlanet Gravity in 2010; there\nis still Pan, Gnus for GNU Emacs; some e-mail clients also have support\nfor Usenet, like Mozilla Thunderbird (and SeaMonkey), Sylpheed and Claws\nMail.\n\nThis technique might not be described in our documentation...\n\nBest,\n-- \nJakub Narębski\n"},{"id":"386032","messageId":"20191112184547.GA38770@google.com","threadId":"51883","inReplyTo":"CABPp-BFXs4qes20S+9AZd++p3epW4eJ7Vu7zU_PdDysZ_D-yrg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-11-12T18:45:47Z","receivedAt":"2019-11-12T18:45:57Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Thu, Sep 19, 2019 at 03:21:08PM -0700, Elijah Newren wrote:\n> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee <stolee@gmail.com> wrote:\n> > 3. Introduce a new \"mentors\" mailing list\n> >\n> > From personal experience, all new contributors at Microsoft (after Jeff\n> > Hostetler at least) have first had their patches reviewed privately by\n> > the team before sending them upstream. Each time, the new contributor\n> > gained confidence about the code and had help interpreting feedback from\n> > the list.\n> >\n> > We want to make this kind of experience part of the open Git community.\n> >\n> > The idea discussed in the virtual summit was to create a new mailing\n> > list (probably a Google group) of Git community members. The point of\n> > the list is for a new contributor to safely say \"I'm looking for a\n> > mentor!\" and the list can help pair them with a mentor. This must\n> > include (a) who is available now? and (b) what area of the code are they\n> > hoping to change?\n> >\n> > As evidence that this is a good idea, please see the recent research\n> > paper \"\"We Don't Do That Here\": How Collaborative Editing With Mentors\n> > Improves Engagement in Social Q&A Communities\" [1].\n> >\n> > [1] http://www.chrisparnin.me/pdf/chi18.pdf\n> >\n> > When asking your first question on Stack Overflow, this group added\n> > a pop-up saying \"Would you like someone to help you with this?\". Then,\n> > a mentor would assist crafting the best possible question to ensure\n> > the asker got the best response possible.\n> >\n> > I believe this would work in our community, too. The action items\n> > are:\n> >\n> > a. Create the mailing list and add people to the list.\n> >\n> > b. Add a pointer to the list in our documentation.\n> >\n> > Note: the people on the mentoring list do not need to be\n> > \"senior\" community members. In fact, someone who more recently\n> > joined the community has a more fresh perspective on the process.\n> \n> Sounds useful for new contributors, _if_ there are enough volunteers\n> with enough time.  I'm a little worried it might be initially staffed\n> well and make a nice splash, but wane with time and possibly even to\n> the point that it makes new contributors more jaded than if we didn't\n> have such a list.  Hopefully my fears are unfounded, as it did sound\n> at the conference like there might be a good number of volunteers, but\n> I just wanted to voice the concern.  (And I feel bad, but I really\n> don't know that I have the bandwidth to volunteer.)\n\nI wanted to bump this thread. With the end of the Outreachy application\nperiod we're left with at least a couple folks who are still interested\nin learning how to contribute, even outside of the scope of the\nOutreachy program. I'm still really interested in participating on a\nmentors list like this; can we set one up?\n\nTo try and summarize what I remember from the summit:\n\n - It's lower pressure for the mentees if git@vger.kernel.org isn't CC'd\n   on all git-mentoring@ emails\n - (But, if we did want to CC the main list, it'd be easy enough for\n   people to filter out the mentoring emails if they don't care?)\n - We should advertise that list in the new contributor places:\n    - CodingGuidelines or SubmittingPatches\n    - mailing list welcome email\n    - MyFirstContribution tutorial\n    + (My own guess is that regularly CCing the main git list when\n      appropriate - that is, when a question would be better posed to\n      the whole community - would help advertise, too.)\n - The idea is less to match a single newbie with a single mentor (as\n   folks are busy), and more to ask the same kind of questions one would\n   usually ask a mentor and be responded to by whoever is available\n\n> Another point that might help here:  New contributors might be\n> surprised by the rigor of the code review process, and might assume\n> they just aren't good enough to contribute.  It might be useful to\n> countermand that subtle unspoken assumption by pointing out how much\n> existing long-term contributors spend revising patches.  Personally,\n> despite doing my best to think of issues and make sure to send in\n> really high quality patches, I still generally expect to spend at\n> least as much time after submitting patches revising them as I did in\n> coming up with them originally, and I'm not surprised if the time is\n> doubled.  And that's after contributing for years.  I don't generally\n> experience reviews anywhere near as thorough in other communities.\n\nI agree with this point. There's a lot to be said about the review\nprocess in open source as compared to the review process \"at home\"\n(internally at your job by people who sit next to you), and I'm not sure\nwhere to say it in the context of the Git project. Maybe the\nMyFirstContribution doc could use a blurb? Hmm.\n\n - Emily\n"},{"id":"386042","messageId":"nycvar.QRO.7.76.6.1911122100220.46@tvgsbejvaqbjf.bet","threadId":"51883","inReplyTo":"20191112184547.GA38770@google.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-12T20:01:23Z","receivedAt":"2019-11-12T20:01:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Emily,\n\nOn Tue, 12 Nov 2019, Emily Shaffer wrote:\n\n> I'm still really interested in participating on a mentors list like\n> this; can we set one up?\n\nI would subscribe immediately to a Git mentors' mailing list.\n\nThanks for bumping this,\nDscho\n"},{"id":"386097","messageId":"CAP8UFD2qjUa=y81YPVSMcuEcDkrkrV=j912qySmG83pig=dFDg@mail.gmail.com","threadId":"51883","inReplyTo":"nycvar.QRO.7.76.6.1911122100220.46@tvgsbejvaqbjf.bet","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-11-13T06:45:34Z","receivedAt":"2019-11-13T06:45:51Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Nov 12, 2019 at 9:04 PM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> On Tue, 12 Nov 2019, Emily Shaffer wrote:\n>\n> > I'm still really interested in participating on a mentors list like\n> > this; can we set one up?\n>\n> I would subscribe immediately to a Git mentors' mailing list.\n>\n> Thanks for bumping this,\n\nI would also subscribe, and yeah I think it might be worth trying.\n\nThere is already a private git-security mailing list\n(https://groups.google.com/forum/#!forum/git-security) on Google\nGroups so perhaps it makes sense to have git-mentors there too.\n\nThanks!\n"},{"id":"386125","messageId":"20191113150624.GC3047@cat","threadId":"51883","inReplyTo":"CAP8UFD2qjUa=y81YPVSMcuEcDkrkrV=j912qySmG83pig=dFDg@mail.gmail.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-11-13T15:06:24Z","receivedAt":"2019-11-13T15:06:29Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 11/13, Christian Couder wrote:\n> On Tue, Nov 12, 2019 at 9:04 PM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > On Tue, 12 Nov 2019, Emily Shaffer wrote:\n> >\n> > > I'm still really interested in participating on a mentors list like\n> > > this; can we set one up?\n> >\n> > I would subscribe immediately to a Git mentors' mailing list.\n> >\n> > Thanks for bumping this,\n> \n> I would also subscribe, and yeah I think it might be worth trying.\n\n+1.  As mentioned in #git-devel during the last standup, I'd like to\nbe on that list as well.\n"},{"id":"386155","messageId":"20191114023100.GD22855@google.com","threadId":"51883","inReplyTo":"20191113150624.GC3047@cat","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-11-14T02:31:00Z","receivedAt":"2019-11-14T02:31:08Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Nov 13, 2019 at 03:06:24PM +0000, Thomas Gummerer wrote:\n> On 11/13, Christian Couder wrote:\n> > On Tue, Nov 12, 2019 at 9:04 PM Johannes Schindelin\n> > <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > > On Tue, 12 Nov 2019, Emily Shaffer wrote:\n> > >\n> > > > I'm still really interested in participating on a mentors list like\n> > > > this; can we set one up?\n> > >\n> > > I would subscribe immediately to a Git mentors' mailing list.\n> > >\n> > > Thanks for bumping this,\n> > \n> > I would also subscribe, and yeah I think it might be worth trying.\n> \n> +1.  As mentioned in #git-devel during the last standup, I'd like to\n> be on that list as well.\n\nChristian's suggestion of a Google Group list was good enough for me.\nFor now, the permission settings are as follows:\n\n - Group visibility: Anyone. (So it can be easier to discover and\n   advertise.)\n - View topics: Group members only. (Maybe we want to open this up so\n   it's easier for non-member Git contributors to take a look at what's\n   going on.... but maybe if they're interested they can just join the\n   group :) )\n - Post: Group members only. (My thinking is that once you're asking for\n   someone's time and effort to help mentor you, you can volunteer the\n   time and effort needed to push the join button and optionally filter\n   your inbox ;) )\n - Join group: Anyone. (Let's make the barrier to entry low.)\n\nhttps://groups.google.com/forum/#!forum/git-mentoring/new\n\ngit-mentoring@googlegroups.com\n\n - Emily\n"},{"id":"386164","messageId":"20191114060650.GC10643@sigill.intra.peff.net","threadId":"51883","inReplyTo":"20191114023100.GD22855@google.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-14T06:06:50Z","receivedAt":"2019-11-14T06:06:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 13, 2019 at 06:31:00PM -0800, Emily Shaffer wrote:\n\n> Christian's suggestion of a Google Group list was good enough for me.\n> For now, the permission settings are as follows:\n> \n>  - Group visibility: Anyone. (So it can be easier to discover and\n>    advertise.)\n>  - View topics: Group members only. (Maybe we want to open this up so\n>    it's easier for non-member Git contributors to take a look at what's\n>    going on.... but maybe if they're interested they can just join the\n>    group :) )\n\nI think it makes sense to stay closed for now. One of the reasons to\nhave a separate group is to make it less daunting to post to. Having a\npublic archive may work against that.\n\n>  - Post: Group members only. (My thinking is that once you're asking for\n>    someone's time and effort to help mentor you, you can volunteer the\n>    time and effort needed to push the join button and optionally filter\n>    your inbox ;) )\n\nIt also cuts down on spam (I moderate the git-security google group, and\nthe spam-blocking is far from perfect).\n\nIt is annoying if things get cross-posted to git@vger (whoever replies\nwith the cc intact will get an annoying \"you can't post here\" bounce).\nBut I'd try it this way for a while and see.\n\n>  - Join group: Anyone. (Let's make the barrier to entry low.)\n\nMakes sense. I just joined.\n\n-Peff\n"},{"id":"386165","messageId":"20191114060833.czrj7v3pf3hnkafg@yadavpratyush.com","threadId":"51883","inReplyTo":"20191114023100.GD22855@google.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-11-14T06:08:33Z","receivedAt":"2019-11-14T06:08:39Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 13/11/19 06:31PM, Emily Shaffer wrote:\n> Christian's suggestion of a Google Group list was good enough for me.\n> For now, the permission settings are as follows:\n> \n>  - Group visibility: Anyone. (So it can be easier to discover and\n>    advertise.)\n>  - View topics: Group members only. (Maybe we want to open this up so\n>    it's easier for non-member Git contributors to take a look at what's\n>    going on.... but maybe if they're interested they can just join the\n>    group :) )\n\nFWIW, I think this should be open to all. Most of the time I first look \nat a few posts of a list before joining, just to get an idea if the list \nis actually what I'm interested in. Restricting topic visibility to \ngroup members only makes doing that impossible. In fact, that's just \nwhat I did before writing this email. I wanted to see what kind of \nmessages are on the list/group before making up my mind if I want to be \na part of it.\n\nSo unless there's some strong reasons to keep it member-only, I vote for \nopening it up.\n\n>  - Post: Group members only. (My thinking is that once you're asking for\n>    someone's time and effort to help mentor you, you can volunteer the\n>    time and effort needed to push the join button and optionally filter\n>    your inbox ;) )\n\nThis I agree with. If you're looking for mentorship, or are providing \nmentorship, you should at least join the group :)\n\n>  - Join group: Anyone. (Let's make the barrier to entry low.)\n> \n> https://groups.google.com/forum/#!forum/git-mentoring/new\n> \n> git-mentoring@googlegroups.com\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"386178","messageId":"20191114100143.GA119027@cat","threadId":"51883","inReplyTo":"20191114060833.czrj7v3pf3hnkafg@yadavpratyush.com","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-11-14T10:01:43Z","receivedAt":"2019-11-14T10:01:49Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 11/14, Pratyush Yadav wrote:\n> On 13/11/19 06:31PM, Emily Shaffer wrote:\n> > Christian's suggestion of a Google Group list was good enough for me.\n> > For now, the permission settings are as follows:\n> > \n> >  - Group visibility: Anyone. (So it can be easier to discover and\n> >    advertise.)\n> >  - View topics: Group members only. (Maybe we want to open this up so\n> >    it's easier for non-member Git contributors to take a look at what's\n> >    going on.... but maybe if they're interested they can just join the\n> >    group :) )\n> \n> FWIW, I think this should be open to all. Most of the time I first look \n> at a few posts of a list before joining, just to get an idea if the list \n> is actually what I'm interested in. Restricting topic visibility to \n> group members only makes doing that impossible. In fact, that's just \n> what I did before writing this email. I wanted to see what kind of \n> messages are on the list/group before making up my mind if I want to be \n> a part of it.\n> \n> So unless there's some strong reasons to keep it member-only, I vote for \n> opening it up.\n\nI do agree with the original decision and think we should keep it\nmember-only.  As Peff mentioned somewhere else in the thread, this\nmakes the group less daunting to post to.  One of the distinct\nadvantages of having a separate mentoring list is to make the process\nof starting to contribute less scary.\n\nI believe that not having all messages public on the internet as\nsomeone is learning to contribute creates an environment where people\nare more likely and comfortable with trying to seek out help.\n\nOf course anyone can join the group, so if someone really wants to see\nthe messages they can, but at least not everyone on the internet can\nstumble upon them, e.g. through web searches.\n\n> >  - Post: Group members only. (My thinking is that once you're asking for\n> >    someone's time and effort to help mentor you, you can volunteer the\n> >    time and effort needed to push the join button and optionally filter\n> >    your inbox ;) )\n> \n> This I agree with. If you're looking for mentorship, or are providing \n> mentorship, you should at least join the group :)\n> \n> >  - Join group: Anyone. (Let's make the barrier to entry low.)\n> > \n> > https://groups.google.com/forum/#!forum/git-mentoring/new\n> > \n> > git-mentoring@googlegroups.com\n> \n> -- \n> Regards,\n> Pratyush Yadav\n"},{"id":"386251","messageId":"xmqqlfsh923p.fsf@gitster-ct.c.googlers.com","threadId":"51883","inReplyTo":"20191114060650.GC10643@sigill.intra.peff.net","subject":"Re: [DISCUSSION] Growing the Git community","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-15T04:48:26Z","receivedAt":"2019-11-15T04:48:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think it makes sense to stay closed for now. One of the reasons to\n> have a separate group is to make it less daunting to post to. Having a\n> public archive may work against that.\n\nYup.  For the same reason, I presume that the list members are not\ndisclosed to the public.  Or perhaps even to the list members?  It\nmight be nice to see who are participating as mentors, though.\n\nAs long as it is easy to point an already-asked-and-answered topic\nto a new mentee, I think that is a sensible thing to do.  We would\nfind it to be inconvenient that we cannot use such an old exchange\nto non-list members, though.\n\n>>  - Post: Group members only. (My thinking is that once you're asking for\n>>    someone's time and effort to help mentor you, you can volunteer the\n>>    time and effort needed to push the join button and optionally filter\n>>    your inbox ;) )\n>\n> It also cuts down on spam (I moderate the git-security google group, and\n> the spam-blocking is far from perfect).\n\nI noticed that, too.  Interestingly, GMail catches these spam that\ncome via the group just fine, so the filter over there may probably\nbe set to be more generous.\n"}]}