diff --git a/_guide-pages/2FA.html b/_guide-pages/2FA.html new file mode 100644 index 0000000000..f8b859dc51 --- /dev/null +++ b/_guide-pages/2FA.html @@ -0,0 +1,227 @@ +--- +title: 2FA Guide +description:
Hack for LA requires two-factor authentication (2FA) in GitHub for all project contributors. +
+in-this-guide: + - name: To Enable 2FA + link: '#To-Enable-2FA' + - name: FAQ + link: '#FAQ' + +--- + +If you already have a 2FA application on your mobile phone, you can use that. If you do not already have a 2FA application you will be instructed to download your mobile app of choice (we have had good luck with Authy) and follow the detailed instructions to complete configuration in GitHub.
+ What is 2FA?
+ +Two-factor authentication, or 2FA, is an extra layer of security used when logging into websites or apps. With 2FA, you have to log in with your username and password, and then provide another form of authentication that only you know or have access to.
+ Read more information about 2FA at GitHub + +Why set up 2FA now?
+Encountering challenges using Git CLI after setting up 2FA? (Developers)
+You might encounter a challenge using the Git CLI after enabling 2-Factor Authentication if you have not used the ssh link for the repo URL.
If you clone via the ssh URL for a repo, e.g.
+git@github.com:hackforla/governance.git
instead of the https URL, e.g.
+https://github.com/hackforla/governance.git
then you probably won't run into any issues after enabling 2FA, as you already use an SSH key.
Read more about connecting to GitHub with SSH.
+Also, these steps might help you get the CLI auth working again:
+Try pushing code from the CLI, if you get rejected unexpectedly it’s 2FA (if you enabled it)
Create a token at GH.com, which you’ll use as your CLI password
If you are still having issues using 2FA with your CLI, please reach out to the #ops channel on the Hack for LA Slack.
+Click any section link below to jump down to its description
This issue is shown in Preview mode
+You can either format with markdown text manually or using the text box toolbar
+ Describe what you’re working on —
+ For a start-to-finish issue, as in this case, choose a title that is generic enough to allow for all phases (research, ideation, design, development).
+ For an issue taking on only part of the workflow, be more declarative in what it covers (e.g. a research issue might be called “Determine Best Testing Library for Code Base”).
+


Clearly state the purpose of this issue in 2 lines or less.
+
+ Markdown draft: ### formats header
+
Final post
+If your issue relies on another issue’s completion first, link to the issue it is dependent on.
+
+ Markdown draft: [title](url) formats links
+
+ Final post
+
+ Formatted as a clickable checklist.
+ If this is the beginning of the task, this is most likely something to be researched and documented.
+ When the research is complete, what will happen next? Describe the steps in your checklist (broadly, if the research will change the details).
+ If the steps can be divided into tasks for more than one person, we recommend dividing it up into separate sections.
+
+ Markdown draft: - [ ] formats checklist
+
+ Final post
+ Final post with checkmarks
++ If there is a link with documentation that helps with this issue, provide the link(s) here. +
+ Markdown draft
+
+ Final post
++ Specify how tasks can be listed in all assignees’ resumés to provide value for project volunteers, divided by roles. +
+ Markdown draft
+
+ Final post
+
+ Select assignees to clarify who is working on specific issues and pull requests.
+ In the upper-right corner, click Assignees. To assign a user (including yourself), start typing their username and click their name when it appears.
+ Assign the issue to only one person at a time, by order of their tasks.
+
+ 
+ Select all relevant labels. See GitHub’s About Labels guide for more details. +
+ 
+ Make sure your issue is added to your team’s Project Board, and properly triaged. Click here to learn more.
+ If the issue has been created but is not ready to assign, it should be set in the ice box.
+ If the issue has been created and is ready but not yet assigned to someone, it should be set in prioritized backlog.
+ When someone has been assigned to the issue, this should be set to in progress.
+

+ You can use milestones to track the progress of groups of issues or pull requests in a repository. Read more at GitHub’s About Milestones guide. +

+ Don’t forget to preview your new issue before posting to make sure it’s formatted correctly. +

Copy/paste the following markdown template text into your new GitHub issue and fill out using the guidelines above.
+ ### Overview
+
+ ### Action Items
+ - [ ]
+ - [ ]
+ - [ ]
+
+ ### Resources/Instructions
+ [link title](link URL)
+
+ ### Resume
+
+ UX Writing:
+ -
+ -
+ UI Mockup:
+ -
+ -
+ Developers:
+ -
+ -
+
+