We are happy to announce a central repository for all the awesome knowledge that the CSU community has to offer. The App Innovation Center of Excellence is your place to share helpful links, code sample, and other best practices that can be shared with our customers.
Backend for GitHub Pages: https://northeastcsu.github.io/CenterOfExcellence
This repo may contain both public and private repo's.
-
Read the Code of Conduct
-
Include the Code of Conduct in your repo's
-
Include a License file in your repo's
-
This Org fully supports diverity and inclusion, please report community actions against the Code of Conduct and feel free to contribute to the Code of Conduct, via Pull Request.
Go to https://aka.ms/submit-coe-content and create an issue based on the content type you would like to submit. Please be sure to fill out all information requested in each entry. Give each submission a unique title and deatiled description. This will ensure the submitted content will be approved to publish on the site.
Content Types
-
Helpful Links
- Links to documentation, blogs, and previously published public information
-
Code Snippets
- Create a Public GitHub gist
-
Best Practice
- Short 1 -2 paragraph blog post.
Please use the following guidelines if creating a new repo in the Northeast CSU GitHub Organization.
General Guidance for OpenSource Repo's
Microsoft Specific Guidance for OpenSource Repo's
Use your personal Github account and Join Microsoft Orgs
How to Choose the Correct License (note MIT should be the default)
How to submit a Pull Request
-========================================================-
-
Keep it organized. Make it easy for team members to find content and understand what was published.
-
Do not use it as a file dump for your code snippets. Instead:
a. Create a Public GitHub gist and submit a code snippet
b. Use your personal Github and submit a helpful link
-
This is a shared site not a personal site.
a. Think through how you use Github Actions. Since this is a shared repo your actions could kick off in unexpected ways.
b. Think through linkages of keys to Azure accounts. If you use a personal key to publish to Azure do others have access to it?
-
Intent is to share useful code artifacts and build off each others work so we are not re-inventing from scratch or duplicating efforts.
-
Documentation can be tedious but it is extremely important. All sites must have a LICENSE file and a well documented README
-
Etiquette: each repo should have an owner and then optionally some contributors. If you are not designated as a contributor already, please ask the owner before contributing how they would like you to contribute (directly or via pull request)
a. If possible: even if you have push rights to your respective repo, you should create a personal (private) fork and then create branches there and raise PR. This will keep main repo clean and your personal workflow out of main repo.
b. If possible always create an issue item
c. Always link the issue in your pull request , also when possible one PR per issue
1. When should I use a private repo?
Private repo's are for internal code artifacts only to share with the team or for artifacts that we receive from 3rd parties under NDA. Or if you are creating a project which will have a significant impact with another team at Microsoft or with a 3rd party.
2. When should I use a public repo?
Public repo's should be the more frequent use case. Consider this repo is for open source development and to share with the community and customers. Always think public first before creating a private repo. When considering as a public artifact make sure it does not duplicate the work of the Azure Media Site.
3. Can I share this site with my customer?
Absolutely, yes. In fact you should share reusable artifacts with customers often as a starting point. Make sure you are using the MIT or GPL License for all code. And make sure it is clear to the customer this is not an officially supported tool from Microsoft. Make sure this content is not redundant with the Azure Media site.
4. Can I add people to this team?
Everyone on the team is a maintainer. Use that privilege with care. Please do not add anyone not on John DeHavilland's team to this site. Consider sharing with others outside our team by forking their repo or directing them to fork our repo's. Then we can use the pull request process for collaborating with people outside of our team.
5. Should I fork a Repo? Should I contribute to a Repo?
Absolutely, building off of the work of others is a key tenant of Github. Forking should be used for anyone outside of our team. This can be another Microsoft FTE, contractor, 3rd party or even a customer. Customers can contribute too, through the pull request process.
For our team, we are all contributors and can directly contribute to repo's.
You can also fork your own personal Github to build on code for our team Github.
6. Should I create a new repo?
Please keep in mind the suggested structure above when creating a new repo. Also consider whether your project is already met elsewhere in the current repo or someone else's repo. Other than that, go for it. Make your project name meaningful. Ensure a description is available for it. And use the README to describe your project thoroughly.
7. When should I use Pull Requests?
Pull requests are awesome. They are useful when collaborating with resources outside of our team site. However, it can also be used by our team for our sites. If someone on the team creates a cool project that they are owning/driving, perhaps ask them if they would like you to directly contribute or issue pull requests for changes.
8. This structure is too rigid, it sucks!!
All of this is initial guidance. The process will evolve. And it is absolutely open to all team input. We can update/change the team guidelines via Pull Request and GitHub Issue Submissions. Use the blank issue submission for feature requests and feedback.