Après plus de 20 ans à produire des logiciels libres tous azimuts, la communauté KDE a mûri et a proposé à ses membres de s'organiser, en se définissant une vision et des objectifs à quelques années.
Cette démarche, « evolving KDE », lancée en 2015, a aboutit l'année dernière à la vision que souhaite servir le groupe (« un monde dans lequel chacun a le contrôle de sa vie numérique et bénéficie de la liberté et de la vie privée »), et pour laquelle 3 buts ont été sélectionnés :
- rendre les logiciels de base plus agréable à utiliser en soignant tous les détails (« utilisabilité et productivité »)
- aider à protéger sa vie privée avec des solutions simples offrant aussi un contrôle fin des données que l'on divulgue
- faciliter l'intégration de nouveaux contributeurs (« embarquement »), en clarifiant les manières de faire et en améliorant les interactions humaines sur différents canaux
Ces problématiques sont dans de nombreuses têtes, je pense notamment à Framasoft, avec sa mission d'éducation populaire aux libertés numériques : l'association cherche des solutions pratiques libres et améliore leur simplicité d'utilisation (1), libère les internautes des grands « aspirateurs d'âmes numériques » (2), et sa nouvelle phase Contributopia encourage chacun à prendre sa part à la construction du beau monde « qui n'existe pas encore » (3).
J'ai en tête de vous parler de ces buts de KDE depuis que les propositions ont commencé à émerger ; ça m'a retitillé en assistant au super show de PYG (framasoft) aux JDLL, et enfin je saisis une occasion pour le faire : quelques membres de KDE viennent de tenir une session de questions-réponses sur reddit (AMA : Ask Me Anything, demandez-moi n'importe quoi) afin de faire le point sur les avancées des ces objectifs après quelques mois…
Les anglophones peuvent parcourir eux-mêmes les échanges, voici quelques extraits que je retiens, but par but :
- utilisation
- Globalement Plasma 5.13 corrige de nombreux détails qui soulagent de nombreux petits maux, j'ai testé et je crois qu'on peut sérieusement le recommander (même aux petites configurations) !
- la prise en charge des machines hybrides (souris+tactile) s'améliore, notamment grâce à Wayland et Qt
- l'interaction avec les navigateurs (notifications, progressions, contrôle médias) est bien plus aboutie
- le système d'indexation (baloo) progresse, avec de vieux bugs corrigés
- anecdote évoquée plusieurs fois : les raccourcis Win+Flèches pour la disposition en pavage sont intégrés ;)
- les paquets complets pour Windows et MacOS sont de plus en plus nombreux, pour conquérir en douceur…
- vie privée
- l'assistant vocal MyCroft s'intègre en local, pour profiter du confort de ces nouvelles interfaces sans faire entrer de grandes oreilles d'espions chez nous
- chiffrer ses données devient plus facile avec les Plasma Vault
- les ordinateurs de poche étant les champions des mouchards, le projet Plasma Mobile est du plus haut intérêt (dans les starting blocks pour le Librem5)…
- pour que votre appareil soit pris en charge, il faut se tourner vers les instructions de Halium/PostMarketOS
- toute application Linux devrait tourner dessus ; pour « écrire une seule fois, exécuter partout » (bureau/mobile), la bibliothèque Kirigami est un outil de choix
- contribution
- une « équipe de bienvenue » se constitue pour répondre aux premières questions et orienter les nouveaux-venus
- les designers sont les bienvenus dans le Visual Design Group
- la rédaction de documentation est un chantier très important, une équipe spéciale doit se monter sur ce thème ; cela passe sur le wiki, tout le monde est invité à apporter sa pierre (son grain de sable ?)
- faire de la promo, sur LinuxFr par exemple, c'est du boulot :P
- vous pouvez donner de l'argent, cela finance avant tout les rassemblements (sprints, et conférence Akademy) ainsi que l'administration et les serveurs…
- on peut installer un environnement de développement quelle que soit la distribution grâce à
appstreamcli get org.kde.development! je ne connaissais pas… - et j'ajouterais que l'équipe de traduction francophone manque de monde, de nombreuses interfaces sont à traduire, sans parler des documentations et différents sites web ! Je ne suis pas toujours très réactif à la coordination, insistez avant de craquer :\
Enfin une citation de Lydia dans la discussion « j'aimerais que les gens comprennent qu'ils peuvent changer le monde qui les entoure plutôt que d'avoir à accepter ce qu'on leur donne » :)
Voilà pour le topo, et je vous encourage encore à aller la rencontre de cette belle communauté !
# Merci!
Posté par gnumdk (site web personnel) . Évalué à 10.
Super journal, je n'avais pas suivi l'AMA sur Reddit donc résumer très intéressant.
Je pense que le point le plus important est la contribution, nous sommes très nombreux à utiliser les logiciels libres mais trop peu nombreux à contribuer…
Souvent, on se dit qu'on a pas les compétences… Et alors? Même si votre code n'est pas parfait, il sera relu, corrigé et en plus d'être fier de contribuer, vous allez apprendre des choses.
Ma première grosse contrib au libre, c'était pour Compiz (placement fenêtres) et Compiz Fusion (Window rules). J'ai d'abord contacté Dave Raveman pour savoir comment m'y prendre et finalement, en quelques jours, j'avais une première version de ce code qui a été utilisé par Ubuntu pendant des années dans Unity!
Seconde grosse contribution, justement c'était sur KDE avec le module kded-appmenu + le code lié dans KWIN (d'ailleurs, la dernière version de KDE intègre mon code porté sous Qt5). Et franchement, les devs de KWIN ont été top, me guidant tout le long de l'intégration de cette fonctionnalité, ce fut une expérience très enrichissante pour moi.
Et pour information, même si j'ai une formation initiale orientée dev (DUT info), ce n'est pas mon métier, je suis admin sys et donc pas besoin d'être une brut pour contribuer à nos bureaux! Je ne m'attaquerai pas à des couches basses qui elles demandent effectivement plus de compétences/connaissances.
[^] # Re: Merci!
Posté par ff9097 . Évalué à 2. Dernière modification le 29 mai 2018 à 10:20.
Mais un peu plus nombreux à vouloir contribuer et abandonner parce que c'est un bordel pas possible. Je ne dis pas ça pour KDE c'est peut-être mieux mais les quelques fois où j'ai voulu contribuer pour un projet il n'y avait pas d'explications claires et centralisés qui expliquaient toutes les étapes, les infos étaient dispersées un peu partout. GitHub a beaucoup aidé pour ça.
[^] # Re: Merci!
Posté par claudex . Évalué à 8.
Du coup, une contribution, ça peut être de faire un guide de contribution.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci!
Posté par ff9097 . Évalué à 3.
Difficile de faire un guide "comment contribuer" sans jamais avoir réussi à le faire
[^] # Re: Merci!
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Faire un rapport de bug ou juste envoyer un mail pour demander "je suis perdu, par où je commence?" c'est déjà d'une grande aide dans ce cas. En tout cas pour les projets ou j'ai mon mot à dire, j'essaie d'être à l'écoute de ce genre de remarques. Et c'est déjà une façon de contribuer.
Le nombre de personnes qui rencontrent un problème mais pensent que les développeurs le savent et ont fait exprès de faire un truc compliqué/qui marche pas est impressionnant…
Quelqu'un (j'ai oublié dans quel projet, désolé!) a utilisé l'expression "vous êtes maintenant expert dans le fait d'être débutant". Et on a besoin de retours de gens qui se sentent perdus parce que nos documentations sont mal organisées, pour savoir quoi améliorer. Parce que nous, on sait ou chercher et on ne se rend pas compte du problème.
[^] # Re: Merci!
Posté par ZeroHeure . Évalué à 7. Dernière modification le 29 mai 2018 à 16:20.
Un grand nombre de gens voient le monde, et plus directement leurs petits tracas, organisés par une grande machine pensante qui nous veut du mal. L'obsolescence programmée sert de justificatif et j'ai bien du mal quand j'explique que non les développeurs de KDE ou Linux ne sont pas à la botte des fabricants de puces, que c'est seulement normal de vouloir utiliser la puissance qu'on a sous la main, ou même de se faire plaisir en exploitant les possibilités graphiques, …
Les rapports de bugs leur paraissent inutiles puisque les développeurs ne les écouteront pas, puisqu'ils sont à la botte d'intérêts trop puissants…
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Merci!
Posté par gnumdk (site web personnel) . Évalué à 4.
Oui, j'ai remarqué aussi, avec parfois un côté bien agressif dans les rapports de bugs.
[^] # Re: Merci!
Posté par Albert_ . Évalué à 4.
Ben c'est normal ils ont rien paye donc forcement ils gueulent…
Les personnes les plus vocales sur les logiciels libres que je connais sont aussi les plus gros pirates de logiciels proprios et ils leur trouvent toujours des excuses quand ca merde…
C'est rigolo, enfin sauf dans les bugs report…
[^] # Re: Merci!
Posté par claudex . Évalué à 10.
Moi je suis très fort, en tant qu'utilisateur, je me dis que les dev sont déjà au courant, voir l'ont corrigé dans la version de développement. Et en tant que dev, je me dis que si personne ne se plaint, les bugs ne sont pas importants.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci!
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 30 mai 2018 à 16:08.
J'ai toujours une attitude similaire (et ce n'est pas une blague) : concrètement je me dis que si j'ai vu un bug, c'est que je l'ai trop tard et/ou qu'il a déjà été signalé et/ou qu'il est déjà connu. Et que s'il n'est pas corrigé dans une version suivante, ben ce n'est pas grave, et si c'est grave pour moi alors à moi de trouver une solution ou un contournement.
C'est l'attitude opposée à celles des râleurs, mais qui n'est pas meilleure car pas plus constructive au final : se dire que probablement le bug est connu, ou qu'il n'est pas grave et qu'on va pas aller faire c**** du monde pour ça.
Après ce constat, il faut aussi dire que ce n'est pas toujours évident de rapporter, lorsque ce dernier demande de re-tester et/ou de trouver une méthode pour reproduire, puis de mettre à jour dans une version différente de celle qu'on utilise, avec des risques, pour voir si le pb se reproduit encore, ou pas.
ABRT est vraiment une très belle avancée pour tout cela : si on a un ou plusieurs comptes sur un bugzilla, tout est automatisé, de bout en bout. Y compris la vérification d'un bug similaire et dans ce cas le bon attachement au bon bug. Même l'anonymisation est facilité. C'est vraiment un remarquable projet.
[^] # Re: Merci!
Posté par vpinon . Évalué à 5.
Carrément !
Prendre la main sur la doc pour la rendre plus claire :
par exemple les instructions que nous avions écrites pour compiler Kdenlive commençaient à sentir le moisi (instructions pour ubuntu 15.04…), petit à petit les contributeurs qui voulaient s'y mettre les ont mises à jour en posant des questions sur la mailing list ou IRC (et pour Windows aussi).
Par contre les indications pour OpenSuse et Fedora n'ont pas été mises à jour et ont donc disparu : ça pourrait être une petite touche facile à ajouter que d'indiquer comment installer les dépendances autrement qu'avec apt ?!
[^] # Re: Merci!
Posté par barmic . Évalué à 2.
Les fondations font aussi ça très bien. Je pense particulièrement à Apache et Eclipse. Ces 2 fondations définissent un ensemble de règles respectées par tous leurs projets (licence, outillage, organisation de projet).
[^] # Re: Merci!
Posté par vpinon . Évalué à 5.
KDE aussi a de telles règles, exigeant notamment une documentation avant qu'une application puisse sortir de "review" vers "release"…
Le problème que souligne David Edmundson dans le AMA est que trop souvent la doc est écrite une fois au début et plus bien mise à jour ensuite :(
Autre souci : KDE offre 3 wikis : userbase, techbase et community, et les docs sont parfois rangées au mauvais endroit ou redondantes… Heureusement ce problème a été déjà bien élagué l'année dernière !
[^] # Re: Merci!
Posté par barmic . Évalué à 2.
Pour ce qui est d'Apache et d'Eclipse il n'est pas demandé de documenter leur organisation, mais que leur organisation se conforme a celle définie par la fondation. Il n'y a pas de question de mise à jour. Tous les projets de chacune de ces entités s'organise de la même façon. Un organigramme est défini et tu connais le rôle de chacun. Ça apporte pleins d'inconvénients, mais tu sais précisément comment ça s'organise.
[^] # Re: Merci!
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Il y a un problème avec la monoculture Github cependant. Je travaille dans certains projets qui ont une organisation différente (pour plein de raisons, on est pas obligés d'aimer le modèle des pull requests et le bugtracker imposé par github par exemple ; mais aussi parce que "ça pue c'est pas libre"). Et on doit passer un temps conséquent à expliquer notre fonctionnement à des gens qui demandent "mais pourquoi vous n'utilisez pas Github?"
[^] # Re: Merci!
Posté par Alex . Évalué à 2.
Pour kde, fut une époque où c'était assez bien fait (c'est ptet toujours le cas, mais je ne contribue plus vraiment), avec un système de junior jobs (des bogues simples à corriger, question d'entrer un peu dans l'archi du projet), et des gens très pédagogues.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.