[TODO Guide] Document how to setup different git persona for personal vs work

[justinabrahms]

This should ideally cover:

1. Setting your global git name / email.
2. Setting a per-repository git name / email
3. Setting up a path-based configuration to automate number 2.

[justaugustus]

1. Setting your global git name / email.
2. Setting a per-repository git name / email

https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git

3. Setting up a path-based configuration to automate number 2.

Example:

❯ cat ~/.gitconfig

[user]
	name = Stephen Augustus
	email = [email protected]
	signingkey = 0x5C9566007B24BDA9
[init]
	defaultBranch = main
[gpg]
	program = gpg
[commit]
	gpgsign = true

[includeIf "gitdir:~/prj/cisco/"]
    path = ~/prj/cisco/.gitconfig

❯ cat ~/prj/cisco/.gitconfig

[user]
	email = ***@cisco.com

ref: https://git-scm.com/docs/git-config#_includes

What's the context / where would this need to live?

[anajsana]

@justinabrahms not sure if you want this content to become a TODO Guide. If so, could you please propose a TOC and a detailed description of what do you expect to see on this guide? 🙂

Also, could you please answer the following questions?

1. Do you have more people interested in working on this guide? if so, do you want to schedule sync guide Zoom calls with the guide participants to review the progress?

2. Do you want TODO to actively look for potential contributors to the guide promoting this issue within the main communication channels (slack, mailing lists, social media)?

3. Following the TODO Guide documentation I can open a PR to work on this guide using a .md file at todogroup.org/guides and add your initial content (to work directly there) 🤔 Are you ok with that?

4. Does it make sense to add in the issue description the participants that are willing to contribute to this guide (and if anyone else shows interest, give them the right permissions to contribute and add them to the list)?

[justinabrahms]

@anajsana I don't need help writing it, but I'd love to know where to put it. The documentation doesn't really feel like a whole "guide", in that it's quite short and focused to a developer audience. Any thoughts on where it should go?

[gyehuda]

At my last company I put together a guide for employees about how to set up their profiles https://yahoo.github.io/oss-guide/docs/resources/your_github.html I think the above content would be a great extention to a follow up guide (I'm not going to update the Yahoo one, but each of us probably have a guide we use for our opsos -- and this is a great topic that we can all benefit from by sharing ideas.

My guide had some things that the above does not have, and the above has things I was missing. So I'm very glad to blend our content together into a page that we could share as a baseline guide that OPSOs can use.

[justaugustus]

Any thoughts on where it should go?

@justinabrahms @gyehuda @anajsana -- Maybe we expand https://todogroup.org/guides/ to include TIL (Today I Learned) quick tips?

I'm not seeing a place where we have content like this.
In an ideal state, my internal documentation is just a bunch of links to TODO Group resources :)

Another thought is expanding guidance in https://github.com/todogroup/outbound-oss?
Right now those docs are geared towards OSPO members, but adding a user/contributor persona may make sense.

[gyehuda]

I had once imagined that TODO group would create a generic OSPO guide that covered the basics and that OSPOs could customize. At Yahoo, I took the Google docs, modified them, and published them (both acknowledging their CC license and adding one to the Yahoo content). Perhaps the generic OSPO guide would then cover 1. Using, 2. Patching, 3. Publishing, 4. Promoting, 5. Launching app with open source / providing attributions, 6. Securing, etc. And there would be subsections like “how to set up your GitHub account” and “what are the different types of open source licenses” that we all have to write. I think it would be cool — but not easy. Or we can deconstruct this into “pages you might want to include in your OPSO guide” Is that too much work? perhaps something smaller like “overheard at a TODOGroup meeting” might be another option? Gil

…

On Mon, Feb 14, 2022 at 4:42 PM justaugustus ***@***.***> wrote: Any thoughts on where it should go? @justinabrahms <https://github.com/justinabrahms> @gyehuda <https://github.com/gyehuda> @anajsana <https://github.com/anajsana> -- Maybe we expand https://todogroup.org/guides/ to include TIL (Today I Learned) quick tips? I'm not seeing a place where we have content like this. In an ideal state, my internal documentation is just a bunch of links to TODO Group resources :) Another thought is expanding guidance in https://github.com/todogroup/outbound-oss? Right now those docs are geared towards OSPO members, but adding a user/contributor persona may make sense. — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACNUSAR3FV5ERXIEAJREULU3FZNTANCNFSM5KJJCRVA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[justaugustus]

Is that too much work? perhaps something smaller like “overheard at a TODOGroup meeting” might be another option?

I think it's a worthwhile effort!
Opened todogroup/governance#190 to track doing an audit of our existing repos to get a better idea of what we can do to tidy up/better organize content.

[anajsana]

FYI @gyehuda (and @justaugustus) there is an Generic OSPO Guide in the OSPO landscape repo intended to gather all TODO existing information (useful info from repos, guides, etc) to have everything ordered into a single place 🙂

It works with a simple .mdfile which makes it quite easy for the community to contribute.

The structure that follows can easily change if people think of a better structure that could better help OSPOs. What about submitting an issue proposing an ideal TOC and expected resources + Follow up this conversation in the slack #project-ospology channel? 🙂

[Sealjay]

As an aside, there are pros and cons to having separately managed identities. I can see some of that in the above material, but we've settled generally on not using enterprise managed identities on GitHub, at least.

We enforce SSO on GitHub enterprise, but people use their typical GitHb username for public open source work, and internal projects.

https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/managing-iam-with-enterprise-managed-users/about-enterprise-managed-users#usernames-and-profile-information

I'm not sure recommending everyone configure their git in this way works for all organisations - maybe it's worth presenting the options, and the pros/cons of each?

[justinabrahms]

I've documented this here: todogroup/outbound-oss#45