-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
English 'Onboarding' and 'Complete onboarding' documentation #261
base: master
Are you sure you want to change the base?
The head ref may contain hidden characters: "216-r\u00E9diger-le-contenu-pour-philosophie-dans-le-wiki-1"
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,42 +2,49 @@ | |
|
||
## Context and objectives | ||
|
||
Why do we need onboarding? What are the objectives of onboarding? what do you | ||
get out of it? | ||
This integration process helps new members get familiar with our environment, tools, and culture. It aims to make them quickly productive and give them an overall understanding of our projects and their impact. | ||
|
||
## CEDILLE philosophy | ||
|
||
- Linux | ||
- Open-source | ||
- Git | ||
- DevOps | ||
- IaC | ||
We aim to bridge the gab between the academic world and the industry by making knowledge and technology accessible to all. We promote open-source, collaboration, and Infrastructure as Code to ensure transparency and simplicity. With a DevOps approach, we encourage continuous experimentation and collective growth. | ||
|
||
We explain why we value these concepts and how they are integrated into our | ||
daily work. | ||
Our club is a space where a passion for technology allows every member to participate, learn, and build concrete projects that serve the student community at ÉTS. We train future engineers to take on real-world challenges, with a drive to innovate and transform the industry today. | ||
|
||
## Our standards | ||
|
||
- Code quality | ||
- Documentation | ||
- Communication | ||
- Git workflow (issue title and description, branch naming, commit message, pull | ||
request title and description, etc. ) | ||
- Git workflow (issue title and description, branch naming, commit message, pull request title and description, etc. ) | ||
|
||
## Domain knowledge | ||
|
||
Insert links into each categories with relevant resources. | ||
Explore the following resources for a solid introduction to the key technologies used at CEDILLE. These links offer foundational knowledge that will be helpful for the hands-on labs. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not against having a link of useful resources here. I do have to ask though - what exactly is our end goal with this list ? Do we want to have a list of useful references for member to peruse at their leisure and refer back to ?if so, there is an argument to be made that maybe this list should be in its own entry page in the wiki where we slowly add the link to the useful references members can read to deepen their understanding of various topic we deem of interest. Do we want to introduce the various list of technology of tools we are using ?(I personally think this is what we want to do)
and each item on the list should have a single link to a short page where the tool in question is introduced. This is already the case for the python and go doc links which point to the page in the official doc where the technology are introduced brievely, the grav link should instead point to What is Grav?, the hugo link should be Introduction to Hugo, etc etc Something else ?maybe ? whatever it is though I suggest that we make it so painfully clear that people don't need to think. |
||
|
||
### App development | ||
* Python | ||
* [Official Documentation](https://docs.python.org/3/tutorial/index.html) | ||
* [Python Examples](https://www.w3schools.com/python/python_examples.asp) | ||
|
||
* Go | ||
* [Official Documentation](https://go.dev/doc/) | ||
* [Go by Example](https://gobyexample.com/) | ||
|
||
### Web development | ||
* Grav | ||
* [Official Documentation](https://learn.getgrav.org/17) | ||
* Hugo | ||
* [Official Documentation](https://gohugo.io/documentation/) | ||
|
||
### DevOps | ||
* [What is DevOps?](https://github.com/resources/articles/devops/what-is-devops) | ||
* [DevSecOps Guidelines](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview) | ||
* [GitHub Actions](https://docs.github.com/en/actions) | ||
* [The DevOps Handbook](https://books.google.ca/books/about/The_DevOps_Handbook.html?id=8kRDEAAAQBAJ&redir_esc=y) | ||
* [The Unicorn Project](https://www.google.ca/books/edition/The_Unicorn_Project/kNSSDwAAQBAJ?hl=en&gbpv=1&printsec=frontcover) | ||
* [The Phoenix Project](https://books.google.ca/books/about/The_Phoenix_Project.html?id=mqXomAEACAAJ&redir_esc=y) | ||
|
||
### SRE (Site Reliability Engineering) | ||
* [Google's Site Reliability Engineering book](https://sre.google/sre-book/table-of-contents/) | ||
|
||
## Onboarding tracks | ||
|
||
Now that you have a good understanding of our philosophy, standards, and domain | ||
knowledge, you can choose a track that fits your profile. Head to the next | ||
section to see the available tracks. | ||
## Hands-on labs | ||
It's time to put into practice what you've just learnt! Click [here](./hands-on-labs/index.md) to get started with the Hands-on labs. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have mixed feeling about this closing thought.
Or really any other closing thought as long as it
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this part is particularly important to nail down, so bear with me.
Technically, we don’t bridge the gap between academia and industry by making knowledge and technology accessible.
So far (and likely for the foreseeable future), we have focused our identity on creating opportunities for members to grow by getting involved in projects. Acquiring and sharing knowledge is a natural side effect of everyone’s involvement in these learning opportunities, but it’s not the primary goal we’re pursuing.
In an ideal world, CEDILLE would evolve into a community hub where people can collaborate, gain hands-on experience, and build knowledge by working on projects that hold significant academic interest to the members or, ideally, tackle real-world challenges to benefit the ÉTS community.
This process of building confidence and skills through contributions to meaningful projects is, I believe, what can help students grow from “sheltered” learners into fully-fledged engineers. Through their work, they should gradually improve themselves and build a portfolio of case studies demonstrating how they’ve added value to the community they belong to. When they graduate and begin looking for career opportunities, this portfolio will act as evidence of the impact they've made and will, hopefully, spark conversations that lead to career advancement.
Well... at the very least, this is the vision I am trying to make a reality.