Benoît Sibaud a écrit 8825 commentaires

« Tu n'es pas Cykon ? »

Ou plus inquiétant, être sur la console du serveur LinuxFr.org…

J'ai ajouté cette ligne en modération, en me basant sur
http://openenergymonitor.org/emon/opensustech qui dit « Following the principles of the Free Software Movement the software source code and hardware designs for this project are available at no cost to everyone under the GNU General Public License. »

Corrigé, merci.

Clarifié dans la dépêche. Merci.

Euh… Diffuser en libre est simple : le repo qui a servi à la compilation, un fichier licence qui va bien et basta.
Sortir en libre ne coûte pas d’énergie, on n'est pas obligé de dire qu'on mettra un support dédié derrière.

J'aurais dit bien au contraire… Tu publies ton code et donc de fait tu dois :

• t'assurer d'avoir les droits qui vont bien pour le faire (pas de contrefaçon, d'incompatibilité de licences, de copier/coller abusif d'autres projets par tes propres développeurs , pas de composants tiers incompatibles, pas de souci dans les composants tiers, etc.). Bref ce que tu aurais dû faire avant, mais bon ton code n'était pas publié, tu avais d'autres priorités, etc.
• t'assurer que ça sera utilisable : que la chaîne de compilation est complète, que rien ne dépend de la fonctionnalité qui n'existe que dans ta boîte, que la doc est bien là, que ça ne repose pas sur LE gars qui sait comment compiler, etc. Oui ça aussi ça aurait été bien de le faire avant mais…
• t'assurer que ça ne nuit pas trop à ton image de marque : pas de code trop sale, pas de commentaires problématiques (injurieux, dénigrants), etc. Oui ça aussi…
• t'assurer que tu as retiré ce que tu ne veux pas y voir (problématique de marques, de logos, de brevets, etc.) et ajouté ce que tu veux y voir (licence, auteurs, etc.)
• arrêter de croire qu'il suffit de juste tout poser en ligne quelque part pour que tout le monde se rue dessus, l'utilise, ajoute de fonctionnalités et en dise du bien en louant ta société.

Globalement je pense que ça vaut le coup (tactiquement/stratégiquement) de publier sous licence libre, sans même parler de l'éthique. Mais ça ne veut pas dire que ça ne coûte rien, qu'il n'y a rien à faire et que c'est trivial.

Je dirais que c'est fait pour être "public", quel que soit le public visé (les modérateurs, les rédacteurs, les visiteurs) et que du coup le nom affiché devrait être celui choisi par le compte concerné. Ça serait ainsi homogène partout sur le site.

La même : https://linuxfr.org/moderation/news/fetons-linux-geneve

Pour les channels/MUC rédacteurs, ce sera ouvert à mon sens, au contraire de modérateurs et admins. Que risque-t-on sans TLS ?

Y a deux choses distinctes :

• protéger le compte du bot et son authentification
• protéger les discussions

ça veut aussi dire qu'il faudrait que la connexion IRC soit faite en SSL/TLS (mais ça n'empêche pas de voir quelqu'un débarquer sur le canal ou dans le salon, et de regarder ce qui ce dit, surtout s'il y a un backlog).

Je n'ai pas compris les usurpations de pseudos… C'est côté IRC seulement ?

C'est en tout cas vrai côté IRC apparemment. Je ne sais pas pour le côté XMPP.

Quel était le bot que tu as utilisé lors des causeries ?

jirc-bridge

Trois solutions libres théoriquement possibles identifiées :

• Jirc-bridge ( https://github.com/kees/jirc-bridge ou http://outflux.net/software/pkgs/jirc-bridge/ ) : packagé Debian en version 1.0 (upstream 1.1). On a déjà de l'expérience avec (notamment avec freenode et geeknode côté IRC, et apinc.org côté XMPP pour le compte du bot et les salons). Pour le moment ne semble pas marcher avec notre compte xmpp de bot en linuxfr.org avec TLS : pas sûr que la couche perl utilisée (POE::Component::Jabber + Net::Jabber) supporte TLS en fait. (jeter un oeil sur Net::XMPP à tout hasard pour voir si c'est utilisable/plus récent/mieux).

• xib ( https://github.com/Changaco/xib ) : packagé Debian, non maintenu upstream, est ou a été utilisé par gulls/vim-fr/osm-fr. Usurpe les pseudos de l'un et l'autre côté (donc ne met pas son pseudo de bot devant celui qui parle). Par contre prend le premier pseudo dispo, peut se retrouver en conflit d'usurpation, utilise une connexion par pseudo, etc.

• telepaatti ( http://23.fi/telepaatti/ ) : non packagé. Nécessite de se connecter à un autre serveur IRC que son serveur habituel.

Corrigé, merci.

Corrigé, merci. Ça doit être le comique de répétition qui permet des marrades.

Corrigé, merci.

Tsss, pas du tout: en réu, on a eu, suivant les cas, des boissons alcoolisées (bière, vin, champagne, spiritueux) et non alcoolisées. On est assez ouverts sur ce sujet-là aussi.

ça a été fait entre-temps ça (cf https://linuxfr.org/redaction/news.atom et https://linuxfr.org/redaction/news/moderation.atom )

Corrigé, merci.

Simple remarque vu le titre du commentaire : l'équipe de modération, elle, a voté pour la publication, et donc la dépêche a été publiée et avait à ce moment là un score positif. Ensuite une partie des visiteurs authentifiés du site a noté pertinent ou inutile ce contenu (et actuellement le score est négatif).

Pour le reste, je suis assez d'accord avec toi.

Fait (insérés après « Proposer une dépêche », ça m'a semblé plus logique).

La ré-attribution de la paternité d'une dépêche étant un peu sensible, il faudrait dans ce cas loguer (dans la table des logs a priori) qu'au temps T, R a réattribué le contenu C de A1 à A2.

Idem pour moi.

L'explication me semble être dans views/dashboard/_drafts.html.haml on utilise la variable "news" au lieu de "drafts".

• juste choisir le login sans authentification : /blabla_url_du_pad?userName=Oumph (cf http://etherpad.org/doc/v1.2.10/#index_embed_parameters )
• vraiment authentifier : voir l'HTTP API http://etherpad.org/doc/v1.2.10/#index_http_api ou http://etherpad.org/doc/v1.2.7/#index_hooks

Il me semble aussi. Corrigé. Merci.

• le stockage de mots de passe pour un autre service (genre un fournisseur de webmail qui te demanderait ton mot de passe sur ton ancien webmail/boîte chez ton FAI pour l'import, ou un bureau virtuel qui vérifierait régulièrement ta boîte de courriel). Et on ne peut pas les hacher de fait.
• malheureusement certains considèrent comme un plus marketing le fait de pouvoir renvoyer son mot de passe à l'utilisateur (donc stockage en clair).

Corrigé, merci.

Visiblement cela a été corrigé dans la foulée.