NotANameServer / discord

Règles et gestion du serveur Discord de programmation Not a Name : https://discord.gg/zcWp9sC
23 stars 9 forks source link

La création du site officiel de Not A Name ! #53

Closed SirMishaa closed 3 years ago

SirMishaa commented 3 years ago

Bonsoir !

On a de plus en plus de ressources, de conseils, de deblog, de membres qui partagent lerus magnifiques projets, la nécessité d'un site se fait ressentir et serait franchement agréable et pertinent.

C'est pourquoi je propose cette issue. L'idée est donc d'avoir un site internet accessible à tous, qui serait communautaire et open source et qui contiendrait différents sujets comme :

SirMishaa commented 3 years ago

Bien sûr, le processus serait complètement itératif, donc on ne va pas réaliser le site complètement. L'idée est de savoir si ça pourrait plaire aux gens et de connaître ce qu'on peut ajouter par la suite.

Mais pour moi, ressources et devblog, ça peut être très cool.

GiregL commented 3 years ago

Juste du point de vue technique, Github Pages ne va pas être limitant pour certaines évolutions futures?

SirMishaa commented 3 years ago

Juste du point de vue technique, Github Pages ne va pas être limitant pour certaines évolutions futures?

Je ne pense pas, sachant que Github Page semble proposer une API, donc en termes de limitation, même si on doit coder un petit daemon qui tourne, on peut facilement mettre à jour le Github via des comportements automatisés.

Aussi, vu que c'est du web, on peut tout à fait avoir une pipeline de build, ce qui fait qu'on peut utiliser des frameworks fontend léger comme Vue ou Svelte pour simplifier énormément le développement de certains composants, pour pouvoir trier / rechercher par exemple.

Et pour les informations, on peut tout à fait avoir les articles du devblog par exemple sous forme de yaml ou de json afin d'éviter un backend. Donc je ne pense pas que nous sommes limités pour ce que nous souhaitons faire.

Mesteery commented 3 years ago

Carrément, si. GitHub Pages va beaucoup nous limiter si nous souhaitons avoir plus de choses qu'un simple blog et quelques pages, genre... les annonces de recrutement... sauf s'ils doivent être faites via des PR, mais dans ce cas c'est un bot qui doit les relayer sur Discord... même si un simple webhook résout ceci (et ce serait valable pour d'autres fonctionnalités).

Je ne pense pas, sachant que Github Page semble proposer une API, donc en termes de limitation, même si on doit coder un petit daemon qui tourne, on peut facilement mettre à jour le Github via des comportements automatisés.

Cette API ne permet pas ce que tu penses.

GiregL commented 3 years ago

Sans parler d'API pour l'OAuth2 et Discord, comment ça se passerait ? J'ai peut-être pas compris (signales le moi si c'est le cas)

En dehors de ça, le projet me semble intéressent. Déjà avant plusieurs d'entre nous ont eu l'idée de faire "Not a Hub", pour héberger nos ressources.

SirMishaa commented 3 years ago

J'aime beaucoup Not a Hub, ça sonne vraiment bien. Pour la partie technique, je vous propose qu'on en parle dans un ticket dédié, si le projet intéresse et qu'il est accepté. Un petit backend sera peut-être, en effet, plus pertinent pour simplifier les choses, au moins, il ne faudra que faire des appels api.

Le fil pour en parler est sur NaN, dans # Not a Hub

GiregL commented 3 years ago

Peut-être plutot dans un thread dans #discussion ? Histoire que tout le monde puisse le voir.

Julien00859 commented 3 years ago

Je suis surtout intéressé par l'aspect blogging, càd pas uniquement des pages type "awesome" qui aggrègent des liens mais vraiment un endroit propice à la rédaction d'articles techniques.

Je publie ici un message que j'avais laissé dans l'ambassade:

[+] Le nom NaH -> Ce n'est pas un composé chimique valide, il manque 6 électrons, il faut trouver un moyen d'inclure de l'oxygène :upside_down:

[+] publier des billets techniques -> mettre l'accent sur la contextualisation du billet, date, version du langage ciblé, ras-le-cul de tomber sur de la doc outdated en ligne

[+] publier des billets d'actu

[+] centralisation des différents blogs

[?] présentation projets de la commu -> nécessaire ?

[?] modèle d'administration -> que le site soit un mirroir de discord, banni de NaN = banni (=readonly) d'hydrure de sodium -> avons-nous besoin de rentrer (si tôt) dans ce qui concerne la modération de la plateforme ?

[-] système de commentaire -> il y a un risque d'éparpiller les conversations, discord devrait rester la principale plateforme pour discuter autours des billets -> peut-être "épingler" sur le billet certains messages de discord ou l'inverse, notifier le bon salon sur discord lorsqu'un commentaire est publié sur le blog (si on ne retient pas la 1e proposition)

=====

-> Avoir un système pour que la communauté puisse valider un article avant sa publication

Alors avant tout, je suis convaincu qu'utiliser git sera une bonne chose, ça nous permettra de proposer des révisions à des articles existants, de documenter les changements et surtout garder une trace de toutes les modifications ce qui est très important pour se donner une rigueur académiques.

D'un autre côté, je constate que les échanges sous les pull requests et les issues sur cette orga ne sont pas forcément très fructueux. Nous sommes très (trop) habitués à échanger entre nous avec des messages courts dans un flux continu d'instant messaging alors que l'utilisation classique de github est plutôt d'envoyer des longs messages où on a toute la largesse d'exprimer ses idées jusqu'au bout (comme je fais ici).

Si je pense qu'on doit garder le mécanisme de pull-request pour proposer des changements, je serais d'avis d'utiliser les nouveaux threads de discord pour les discussions (et même les reviews) et empêcher d’interagir sur l'interface de github. On peut utiliser les webhooks pour ça :)

J'aime beaucoup la proposition d'utiliser les github pages par contre j'ai très peur de subir l'élan technologique des développeurs Javascript. Si on doit faire un blog j'aimerais vraiment réduire toute la technique au stricte minimum : pas de preprocesseur css, pas de javascript inutile, pas de framework css (bootstrap/foundation), pas de syntaxe abusivement complexe pour le texte (I'm looking at you reStructuredText). Vraiment, gardons le bon vieux html5/css3/markdown que tout le monde peut comprendre, mettons juste un post-commit-hook capable de run un script de rendu markdown -> html.

Dans mon idée, proposer un article (ou une révision) devrait se résumer à écrire (ou modifier) un fichier markdown et proposer une pull-request. Les métadata (data/auteur) peuvent être sorties des commits. Comme le mécanisme des :pushpin: sur discord, à partir du moment où l'ambassadeur du salon/un membre du staff/10 membres sont d'accords avec une PR, elle pourrait être mergée.

Qu'en pensez-vous ?

Julien00859 commented 3 years ago

Up, en suivant les messages dans le thread sur discord, les points suivants ont en plus été abordé:

On aurait notre thème perso concocté par les devs html/css du serveur, on aurait les métadata en préamble de chaque fichier markdown, pour classifier/catégoriser les articles on placerait chaque fichier markdown dans un dossier lui allant bien (on a proposé de reprendre la structure des salons de discord).

SirMishaa commented 3 years ago

Petite précision, peu importe la techno qu'on va choisir, on aura une documentation adaptée au débutant pour pouvoir y contribuer. Néanmoins, il est quand même temps de parler de nos choix au niveau technologiques. Nos besoins sont donc de mettre en place un site communautaire, avec une partie devblog, ressources, recrutements, vidéo & streaming, partie vos projets et d'obtenir les données via le serveur discord, le tout via une interface à minimum propre. On aura besoin de filtering, de recherche, de listing et d'une facilité pour la modification des données.


Donc certe c'est important d'avoir un truc léger et facile d'approche pour les débutants, mais pensez quand même qu'il va falloir le développer le site ainsi que le maintenir et être flexible pour y ajouter des éventuelles fonctionnalités. Et aussi, c'est du Web, donc si on ajoute certaines features comme la possibilité d'avoir une recherche et de filtrer pour les recrutements par exemple, bah quoi qu'il arrive, on aura besoin de Javascript, ou du filtering côté serveur (donc d'un backend).

Je préfère préciser car mon objectif, notre objectif je pense, est de développeur un site cool pour la communauté, qui fonctionne bien et ou l'on peut ajouter des fonctionnalités sans être une purge à maintenir. Donc de ce fait, il y aura forcément des prérequis quant au développement du site en lui-même, néanmoins, pour les ressources, il est néanmoins une très bonne idée d'avoir du Markdown et de laisser le serveur faire le serveur de son côté afin de garder la facilité pour ajouter des articles ou modifier certaines parties du site.

SirMishaa commented 3 years ago

Donc si je dois mon avis de développeur web, en prenant en compte les facteurs suivants :

Je pense franchement que Javascript l'emporte, c'est un langage qui est vraiment simple (en plus on fera une doc sur le repo), qui ne nécessite que NodeJS qui est plutôt léger, qui est quand même très populaire.

Certe, ça fait un peu chier, (moi je voulais faire du Rust 😒) mais objectivement parlant, il sera très simple et rapide de développer le site et ça restera noob-friendly.

Il y a aussi d'autres points, comme le fait que Visual Studio Code le supporte nativement avec de la bonne autocomplétion, que l'écosystème derrière est très big. Qu'on peut arriver à garder les choses très simples et complet en même temps, etc...

Si vous avez des remarques, n'hésitez pas !

Dernière petite précision, mais les données des articles et diverses petites choses vont rester en format markdown, afin de rester très simple. Keep it simple.

@Julien00859 Je n'oublie pas ton commentaire concernant l'élan technologique des développeurs Javascript et c'es vrai que tu as raison, mais le fait est que, pour le site qu'on souhaite réaliser (donc un peu plus qu'un blog) il est quand même très difficile de garder juste de l'HTML & CSS, sans aucun backend ni rien.

Donc pour moi, on va devoir surtout faire en sorte que tout reste vraiment simple, via de la doc, des règles, etc... Mais je ne pense pas qu'on y échappera à un minimum de complexité.

florentm35 commented 3 years ago

Avant de vouloir choisir une techno, il pourrais être intéressant de faire un cahier des charges détaillés, ainsi que voir comment serait réalisé ce site.

Julien00859 commented 3 years ago

Je lis les deux messages de MIshaa et je constate qu'on est en plein dedans, l'élan technologique des développeurs JS.

Julien00859 commented 3 years ago

Concernant spécifiquement le point sur le recrutement, honnêtement je suis assez opposé à accueillir sur un site de NaN des articles relatif au recrutement. Les gens qui viennent faire du recrutement sont essentiellement des HR qui n'apportent intrinsèquement rien à NaN si ce n'est un nouveau message qui apparait de temps à autre dans #offre. Je suis assez opposé à leur donner encore plus de visibilité au travers d'une section qui leur serait dédié sur le site.

SirMishaa commented 3 years ago

Bon du coup, on est revenu en arrière côté techno suite à une discussion avec @Julien00859 On va garder les choses extrêmement simples avec Github Pages

Et s’il y a éventuellement des petites parties JS à écrire, elles seront écrites à la main, au plus simple possible. Donc absolument tout le monde peut y contribuer.

Julien00859 commented 3 years ago

https://github.com/NotANameServer/Not-a-Hub