Discussion:Version 0.6.6

Votes 0.6.6 second tour

Pour information, voici les archives du 1^er tour.

La version provisoire a été établie à partir des résultats définitifs du premier tour (très léger avantage pour le @ en terme de nombre de votants), ainsi que suite à des discussions sur IRC pour la place devenue vacante du µ (le grave mort très utilisé en Shell Unix s'étant retrouvé en Shift-AltGr). Si ces choix ne vous conviennent pas, il est encore temps de vous exprimer ci-dessous (il ne s'agit que d'une version provisoire).

Êtes-vous d'accord avec la version provisoire sur la page de l'article

Votez pour l'une des propositions suivantes

• Oui, l'arrobe sur [6] me va bien :

┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔════════╗
│ #  │ 1  │ 2  │ 3  │ 4  │ 5  ║ 6  │ 7  │ 8  │ 9  │ 0  │ ^  │ `  ║        ║
│ $  │ "  │ « <│ » >│ ( [│ ) ]║ @  │ +  │ -  │ /  │ *  │ =  │ %  ║ <--    ║

• Euh, l'arrobe sur [6] me va bien à condition de regrouper les tirets cadratin en AltGr+[1] :

┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔═════════╗
│ # ¶│ 1 –│ 2 ≤│ 3 ≥│ 4 “│ 5 ”║ 6  │ 7  │ 8  │ 9  │ 0  │ ^  │ `  ║         ║
│ $ §│ " —│ « <│ » >│ ( [│ ) ]║ @  │ + ±│ - -│ / ÷│ * ×│ = ¬│ % ‰║ <--     ║
╔════╧══╗─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─┴──┬─╚══╦══════╣

Hum. Je n'ai pas saisi la totalité de l'impact de cette modif (les caractères déplacés)Asr 16 mai 2008 à 06:48 (UTC)

Le tiret demi-cadratin passe de AltGr+6 à Shift+AltGr+1, et est remplacé par le signe « - » mathématique. Kaze 16 mai 2008 à 07:05 (UTC)

• Non, je veux le tiret cadratin en direct sur [6] (cf les archives du 1^er tour)

┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╔════════╗
│ #  │ 1  │ 2  │ 3  │ 4  │ 5  ║ 6  │ 7  │ 8  │ 9  │ 0  │ @  │ `  ║        ║
│ $  │ "  │ « <│ » >│ ( [│ ) ]║ —  │ +  │ -  │ /  │ *  │ =  │ %  ║ <--    ║

Votes concernant la procédure à suivre pour la v1.0

Lors du premier tour 22 personnes se sont prononcées pour « organiser un autre vote pour décider si on fige ou non les caractères principaux après la sortie de la 0.6.6 », en sachant que cela conduirait à une série de « release candidate ». Il reste encore à clarifier ces points.

Comme on ne va pas multiplier les votes intermédiaires, voici en parallèle des points ci-dessus quelques propositions.

Qu'entend-t'on par « caractères principaux » ?

TODO:

• les lettres ?
• les lettres et les caractères de ponctuation ?
• les lettres et tous les caractères obtenus sans AltGr ?
• les lettres et les caractères de ponctuation et les caractères fréquents en informatique ?

Feuille de route

Ce pourrait être :

1. figer les positions des lettres ;
2. définir et figer la carte simplifiée, toutes les propositions concernant les lettres étant désormais irrecevables — à l'issue de quoi, on dispose d'une première Release Candidate ;
3. définir et figer la carte complète, toutes les propositions concernant la carte simplifiée étant désormais irrecevables — à l'issue de quoi, on a une v1.0.

Il faudrait préciser les modalités de vote, par exemple : on pourrait, dès le prochain vote, proposer de voter de figer la position des lettres, le vote n'étant recevable que si aucune modification des lettres n'est acceptée dans le même vote. Et si nécessaire, on repropose de figer les lettres lors des votent qui suivent, jusqu'à ce que ça soit accepté. Puis idem pour la carte simplifiée, et pareil pour la carte complète. Kaze 15 mai 2008 à 23:53 (UTC)

Ou encore :

1. Figer la liste des points bloquants à résoudre (et plus de propositions nouvelles hors ces points)
2. S'atteler à ces points et uniquement ceux-là
3. Figer les caractères principaux quand aucun nouveau point bloquant n'apparait (et Release Candidates à ce point)
4. v1

Si on fige la liste des points bloquants en #1, le point #3 devient « figer les caractères principaux (et Release Candidates à ce point) ».

Ce qui m'inquiète, c'est que le terme « points bloquants » est ambigu et hautement subjectif. Qu'est-ce qui différencie un point bloquant d'une simple amélioration ? Comment faire pour que la liste des points bloquants ne devienne pas un doublon de la page de discussion du prochain vote ? Est-ce qu'il faudra voter pour valider chaque point bloquant, puis voter pour une façon de le résoudre ? Et si un point bloquant n'a pas de solution simple (ex : place du W), est-ce que ça ne bloquera pas tout le processus ?

Par ailleurs, je crains que de figer la liste des points bloquants ne revienne plus ou moins à s'interdire de trouver de bonnes idées non « boxogènes » pour la 1.0 — ou pire, à s'interdire de corriger des problèmes qui pourraient apparaître après les changements récents.

Cette liste de points bloquants est un bon outil, qu'il serait dommage de boxonifier en le soumettant au vote. ;-) Kaze 15 mai 2008 à 23:53 (UTC)

Toutafé. Figeons la carte simplifié, et gardons à l'esprit les points bloquants.

Pour ce qui est du boxogène, l'algorithme du recuit simulé censé résoudre les problèmes np-complets – dont fait partie le clavier BÉPO – prévoit une marge de manoeuvre de plus en plus étroite à mesure de l'avancée des recherches de solution. Ceci, afin de s'autoriser des sautes en arrière de plus en plus réduites, et convirger vers un optimum le plus approchant de l'optimum global.

Je crois qu'il faut que nous commencions à restreindre la portée des changements proposés. Asr 16 mai 2008 à 06:56 (UTC)

Puis une fois cette section faite (TODO)

Approuvez-vous la feuille de route ci-dessus ?

• oui
• non