Skip to content
This repository was archived by the owner on Sep 22, 2025. It is now read-only.
David Samuel edited this page Nov 16, 2023 · 32 revisions

GitHub Policy

Source todo link to sharepoint document

4.5 .gitignore: Utilise a .gitignore file to specify which files or directories should be ignored by Git to prevent unnecessary files from being committed to the repository. 4.6 Documentation: Maintain comprehensive and up-to-date documentation for projects, including usage instructions, installation guides, and troubleshooting tips. 4.7 Archiving Repositories: If an application is no longer used in production and there is no update on the repository for the last 01 year, the Technical Lead or nominated Sr. team member should archive the repository, Update the README file accordingly and resolve any open security alerts on the repository. 12:56 4.1 Team Names: Use clear and descriptive names for teams and organisations to help members understand their purpose. 4.2 Collaboration through teams: Only teams should be granted access to repositories. This makes it clear why the access is needed and helps to ensure people have correct permissions within team moves. If there is an explicit need for an individual to be granted access this should be agreed with Technical Lead or nominated Sr. team member. Action for future: Add the documentation once we have automated process in place. 4.3 Code of Conduct: ONS encourages respectful and inclusive interactions on GitHub. Adopt and adhere to a code of conduct to ensure a welcoming and harassment-free environment for contributors. 4.4 Collaboration Workflow: Collaborate effectively by using pull requests for code reviews and discussions. Use issues and discussions to track and discuss project changes and enhancements. 4.5 Unsolicited pull requests: If we get an unsolicited pull request from outside of the organisation it must not be merged. It should be raised to the Technical Lead or nominated Sr. team member. 4.6 Branching Strategy: Implement a clear and effective branching strategy (e.g., feature branches, release branches) to organise and manage code changes. 4.7 Branch Protection rules: Use of Branch Protection rules must be used to enforce security policies by preventing accidental branch deletions, enforcing code reviews, and requiring successful automated checks before pull requests can be merged etc. 4.8 Signed Commits: Use of signed commits are encouraged, so other people can verify that your work comes from a trusted source. If a commit or tag has a GPG or S/MIME signature that is cryptographically verifiable, GitHub marks the commit or tag as verified. 12:56 5.1 Privacy Settings: Review and adjust your privacy settings on GitHub to ensure that your contributions and personal data are appropriately protected. 4.7 Security: Regularly review and update dependencies to address security vulnerabilities. Utilise automated security tools and services to identify and remediate vulnerabilities. 5.2 Compliance: Ensure that all GitHub activities and repositories comply with applicable laws, regulations, and organisational policies. Be aware of any data protection or export control regulations. 12:57 6. Continuous Integration and Deployment (CI/CD) 6.1 CI/CD Pipelines: Where appropriate use GitHub Actions to implement CI/CD pipelines to automate testing, building, and deployment processes. Action for Daniel O’Brien: Provide recommendation/policy for using the GitHub Action. 7. Reporting Issues 7.1 Reporting Security Concerns: Report security vulnerabilities or suspicious activities immediately to the appropriate contact within the Organization or follow the established incident reporting procedures. Action for Fahad: Link to Security (Depenabot alert is not included in it) 8. Compliance and Enforcement 8.1 Policy Violations: Violations of this GitHub Usage Policy may result in consequences, including warnings, access revocation, or other disciplinary actions, as determined by the Organisation. 8.2 Policy Enforcement Teams: Designate a policy enforcement team or individual responsible for monitoring and enforcing policy compliance. 8.3 Periodic Audits: Conduct periodic audits of repositories, teams, and access permissions to ensure compliance. Use automation to assist in auditing and reporting.

Clone this wiki locally