The GC DevOps League is a grassroot movement that has spawn off of a collective desire to change our ways of working, both from a software development and IT operations practitioners' perspective.
The league is open to anyone interested in working in the open, sharing their lessons learned and helping each other take over the challenges that we all have to deal with, even though we come from various organisations deemed "different". We're much more alike than some might want to let you believe.
As it is, we do not have a "Membership" process. This is an open community where everyone can contribute in their own way. However, we do have a Code of Conduct and we encourage you to read it carefully because we want this community to be inclusive and diverse.
With regards to the "member" status of the GitHub organisation (more details below), they have been created to maintain the documentation and plan events. If you are interested in having a more active role, please request to be added to the "members" of the organisation. If you do not have the time to review documentation, merge pull requests, organize events, it's absolutely fine and you can simply star the repos that interest you, create issues, participate to discussions or submit "Pull Requests" to suggest changes.
We do not expect everyone to take time off their regular work schedule to do so. But we collectively benefit from any contribution made, no matter how small it may seem to you as an individual.
The GC DevOps League uses various channels of communications.
- GitHub
- GCMessage
- Slack
The GitHub "organisation" is a way for us to aggregate information material and documentation in the open. Individually, we do not know everything and, even as a group, we can benefit from having our discussions in the open. Other organisations and teams have already gone through the process of changing their practices to be more inclusive and open. Anyone is welcome to provide us additional insights as we go through our collective journey.
One thing that we have observed is that a lot of the information, guidance and tools available out there seem to be tailored for businesses. As employees of the federal government, we have a different set of responsibilities towards the citizens and we will most likely have to tailor this external knowledge to the laws and internal rules that we are bound to. Our work may also be useful to help better adapt our internal rules to the outcomes expected by our citizens in this time and age: becoming a Digital Government providing services of value to them.
Within this "organisation", we have created repositories that aim to address certain topics. These repositories will change over time as we better see how our community evolves. Each repository has an "Issues" section where anyone can start a conversation. These "Issues" are not necessarily problems, but rather discussions topics. You are welcome to create or participate in an issue for any topic you would like.
If you are interested to become a member of the GitHub organisation, which means having additional "write" access rights on the repositories, please note that we require you to use 2FA.
This is in line with the best practices recommended in Treasury Board of Canada Secretariat Direction (Appendix B, For Managers), but also GitHub itself, general online best practices here, here, here and here.
In fact, we urge you to enable 2FA for any web service you are using.
If you're asking "Why? This adds complexity, ney, PAIN to my workflow... Uh, too much wooooork!", you probably never had to deal with someone stealing your FREE web service account.
Companies offering free web services are happy to provide you with automated ways to secure your account because they don't have thousands of lined up level 1 support staff to reset your password. If you somehow have your account stolen, most of them will not offer any service to get it back to you. That then means that the perpatrator gains access to your content (whether email, entire coding profile, pictures, etc.) and starts impersonate you.
On our end, what this means is that, since this is a free organisation, we don't see your email address (and don't want to) and we have no way to give you back your account. Our only recourse is to kick this account out of the members.
There are, of course, challenges introduced with 2FA. It's an additional step to perform certain tasks, you need to generate keys to use HTTPS URLs with Git instead of your regular password, etc.
Based on our needs as an organisation, the benefits of 2FA outweight the burden of using it.
La Ligue DevOps du GC est un mouvement populaire qui est né d'un désir collectif de changer nos méthodes de travail, tant du point de vue des praticiennes et praticiens du développement de logiciels que des opérations informatiques.
La Ligue est ouverte à toute personne intéressée à travailler ouvertement, à partager ses leçons apprises et à s'entraider mutuellement pour relever les défis auxquels nous devons toutes et tous faire face, même si nous sommes issus de diverses organisations considérées "différentes". Nous nous ressemblons beaucoup plus que certains voudraient nous faire croire.
Pour l'instant, nous n'avons pas de processus "d'adhésion". Il s'agit d'une communauté ouverte où chacune et chacun peut contribuer à sa façon. Cependant, nous avons un code de conduite et nous vous encourageons à le lire attentivement parce que nous voulons que cette communauté soit inclusive et diversifiée.
En ce qui concerne le statut de "membre" de l'organisation GitHub (plus de détails ci-dessous), ils ont été créés pour maintenir la documentation et planifier les événements. Si vous souhaitez jouer un rôle plus actif, veuillez demander à être ajouté aux "membres" de l'organisation. Si vous n'avez pas le temps d'examiner de la documentation, de réviser et fusionner des demandes de "Pull Request", d'organiser des événements, c'est absolument correct et vous pouvez simplement mettre en favoris les repos qui vous intéressent, créer des problèmes (Issues), participer à des discussions ou soumettre des "Pull Requests" pour proposer des modifications.
Nous ne nous attendons pas à ce que tout le monde mette du temps en dehors de son horaire de travail habituel pour le faire. Mais nous bénéficions collectivement de toute contribution, aussi minime qu'elle puisse vous sembler en tant qu'individu.
La GC DevOps League utilise divers canaux de communication.
- GitHub
- GCMessage
- Slack
L'"organisation" de GitHub est pour nous un moyen de rassembler des informations et de la documentation au grand jour. Individuellement, nous ne savons pas tout et, même en tant que groupe, nous pouvons tirer profit de discussions ouvertes. D'autres organisations et équipes ont déjà entrepris de modifier leurs pratiques afin d'être plus inclusives et ouvertes. N'importe qui est le bienvenu pour nous fournir d'autres idées au fur et à mesure que nous avançons dans notre cheminement collectif.
Une chose que nous avons observée, c'est qu'une grande partie de l'information, des conseils et des outils disponibles sur le marché semblent être adaptés aux entreprises. En tant qu'employés du gouvernement fédéral, nous avons un ensemble différent de responsabilités envers les citoyens et nous devrons très probablement adapter ces connaissances externes aux lois et aux règles internes auxquelles nous sommes liés. Notre travail peut également être utile pour aider à mieux adapter nos règles internes aux résultats attendus par nos citoyens à notre époque : devenir un gouvernement numérique leur fournissant des services de valeur.
Au sein de cette "organisation", nous avons créé des référentiels qui visent à traiter certains sujets. Ces dépôts changeront au fil du temps à mesure que nous verrons mieux comment notre communauté évolue. Chaque référentiel a une section "Problèmes" où n'importe qui peut commencer une conversation. Ces "Questions" ne sont pas nécessairement des problèmes, mais plutôt des sujets de discussion. Vous êtes invités à créer un numéro ou à participer à un numéro pour n'importe quel sujet que vous aimeriez.
Si vous êtes intéressés à devenir membre de l'organisation GitHub, ce qui signifie avoir des droits d'accès "écriture" supplémentaires sur les dépôts, veuillez noter que nous vous demandons d'utiliser 2FA.
Cela est conforme aux pratiques exemplaires recommandées dans la directive du Secrétariat du Conseil du Trésor du Canada (annexe B, Pour les gestionnaires), mais aussi GitHub eux-même, les pratiques exemplaires générales recommandées en ligne là, là, là et là.
En fait, nous vous conseillons vivement d'activer 2FA pour tout service Web que vous utilisez.
Si vous vous demandez "Pourquoi? Ça ajoute de la complexité, nah, de à mon flux de travail", vous n'avez probablement jamais eu affaire à quelqu'un qui vous a volé votre compte de service Web GRATUIT.
Les entreprises offrant des services Web gratuits sont heureuses de vous fournir des moyens automatisés de sécuriser votre compte parce qu'elles n'ont pas des milliers d'employés de soutien de niveau 1 en ligne pour réinitialiser votre mot de passe. Si vous vous faites voler votre compte, la plupart d'entre elles n'offriront aucun service pour vous le rendre. Cela signifie alors que le contrevenant ayant volé votre compte accède à votre contenu (qu'il s'agisse d'un courriel, votre portfolio complet de contributions libres, d'images ou autres) et qu'il peut maintenant se faire passer pour vous.
De notre côté, puisqu'il s'agit d'une organisation gratuite, nous ne voyons pas votre adresse e-mail (et ne voulons pas le voir) et nous n'avons aucun moyen de vous rendre accès à votre compte.
Notre seul recours est de radier ce compte de nos membres.
Il y a, bien sûr, des défis introduits par la 2FA. C'est une étape supplémentaire pour effectuer certaines tâches, vous devez générer des clés pour utiliser les URL HTTPS avec Git au lieu de votre mot de passe habituel, etc.
Sur la base de nos besoins en tant qu'organisation, les avantages de 2FA l'emportent sur le fardeau de son utilisation.