Discussion:Version 1.0rc1/Archives

Validation de la page de vote

Je m'y prends un peu tôt, mais je veux être sûr de ne pas oublier ce que je voulais dire… Je propose que la page de vote fasse l'objet d'une approbation générale avant le vote proprement dit (en rajoutant simplement une section à la page de discussion quelques jours avant le début du vote, dans laquelle les gens peuvent faire part de leurs remarques). Ceci pour éviter des « surprises » comme pour la version 0.6.6, pour laquelle est apparue (le mot est fort, j'ai bien remarqué après coup que cette proposition n'était pas récente puisqu'elle a été ajoutée le 9/04) par exemple une proposition concernant l'ajout des chiffres en indices (excellente idée du reste, mais dont il n'a pas été discuté), ou encore l'absence des propositions d'inversions simples RN/JF pourtant plébiscitées (Nemolivier, concernant ta réponse à mon interrogation, les stats sont peut-être rédhibitoires mais il n'y a pas que les stats dans la vie : elles sont un élément déterminant, mais ne doivent pas faire oublier que chacun utilise son clavier différemment, et que le confort de l'utilisateur est le but final… Et pour mettre les choses au clair, non, je ne défend pas l'inversion simple (j'espère d'ailleurs qu'on en a définitivement terminé avec ces 4 lettres…)). Donc, prenons quelques jours avant le vote pour se mettre d'accord sur les propositions à garder et leurs formulation. Skippy le Grand Gourou 29 avril 2008 à 09:48 (UTC)

Il y a eu 15 jours de vote et une semaine de nettoyage de ces dits votes. Nemolivier 29 avril 2008 à 10:15 (UTC)

Yep, il y a en effet eu les 15 jours de propositions et la semaine de nettoyage. Ceci dit les complaintes de Skippy ne sont pas infondées. Voici quelques remarques et suggestions générales (non ciblées personnellement sur Nemolivier ou Skippy) pour la prochaine fois (et a fortiori si on a pas de 0.6.7 mais une RC que l'on prétendrait « stable »):

• Plus de temps pour la mise en forme. Nous étions encore sur la mise en forme la veille au soir tard, après un WE où nous avons passé beaucoup de temps personnel pour le projet. On ne pouvait pas tous non plus participer en semaine. Malgré cela il restait encore des petits détails à règler le jour du vote.
• Avec le temps du point précédent, on pourrait répondre à la requête de Skippy en annonçant sur la ML une demande de relecture de la page de votes quelques jours avant la phase de votes. Là c'eut été impossible, avant le WE la page n'était pas prête (Je réponds ici à Skippy : on a pas malheureusement pas eu le temps de faire valider la page).
• Améliorer le système de vote. On pourrait comme il a été suggéré sur IRC utiliser un système de vote comme par exemple le vote pondéré où on note les propositions par ordre de préférence (y compris préférences négatives dans cet exemple).
• Plus de temps également pour les propositions : certains n'ont pas pu émettre des propositions pour la 0.6.6 car ils n'avaient pas accès à Internet (si je me souviens bien avoir lu ceci sur IRC). Sur ce point, il suffirait d'ouvrir une page permanente « propositions pour la prochaine fois » et de l'archiver pour la dépouiller lorsqu'on souhaite faire une nouvelle version. Ou alors simplement de ne faire de nouvelle version que lorsque cette page devient assez chargée, et de faire une version stable si trop peu de changements ont étés proposés en un temps fixé (quelques mois). Ce pourrait être un principe pour une branche de développement.
• Plus de temps surtout pour les votes. Certains n'ont pas pu voter pour la 0.6.5.1… suffit d'être en déplacement ou vacances au mauvais moment, et c'est trop tard pour voter.
• Garder toutes les propositions émises, quelles qu'elles soient (je pense à RN et FJ). À moins de choisir un système de vote très bizarre, les propositions les moins bonnes et/ou très minoritaires seront de toutes façons éliminées.
• Réouvrir une page de discussion pour les arguments des uns et des autres en cours de vote. Pour ce dernier point il n'est d'ailleurs pas trop tard !

Nbrodu 29 avril 2008 à 12:29 (UTC)

Je viens de réaliser le dernier point ici. Fredb219 29 avril 2008 à 12:59 (UTC)

Pour l'ajout des chiffres en indice, vu que ça te tient à cœur et que ça fait trois fois que tu nous rabaches ça, c'est un truc dont on a parlé sur irc il y a bien longtemps, en même temps que l'ajout des exposants. Sauf que ça avait été oublié à la 0.6.5/0.6.5.1. Il ne faut pas croire que cela tombe du ciel ! On est une vingtaine toute la journée à piailler sur irc et ce n'est pas parce que ça n'est pas sur le wiki que ça n'a pas été discuté. Le hatchek pour les indices à côté du circonflexe pour les exposants, même touche, même « utilité ». À noter d'ailleurs que sans irc, le wiki ne ressemblerait jamais à ce qu'il est aujourd'hui. A2 29 avril 2008 à 13:18 (UTC)

Et vu le nombre de Contre sur cette proposition on peut se demander si l'absence de discutions ne vient pas tout simplement d'une absence de désaccord. Par rapport au vote je trouve cela non pertinent car il y a eu un mail pour le calendrier et personne n'a présenté le moindre désaccord.

Par rapport à l'accès internet c'est un faux problème, il y a 2 semaines de vote, donc largement le temps de voter (ou sinon on peut mettre un système de procuration) et les propositions rien n'empêche à quelqu'un qui n'a pas internet de donner sa proposition via ML en demandant qu'elle soit intégrée à la prochaine version.

Pour le système de vote je suis d'accord que de pouvoir voter par préférence ou au moins contre une sous proposition sera une avancée.Tiot 29 avril 2008 à 14:04 (UTC)

• J'estime pour ma part que la date du vote ne doit pas être forcément inéluctable, on n'est pas à deux jours près…
• L'ajout des chiffres en indices ne me tient pas particulièrement à cœur (excellente initiative, et je n'ai rien à redire sur la position), simplement ça avait effectivement l'air de surgir de nulle part au moment du vote (a priori un oubli lors de l'ajout sur la page principale). Question de principe donc (idem pour les inversions).
• C'est sans doute un tort, mais tout le monde ne souhaite pas nécessairement s'investir dans (ou n'apprécie pas forcément, c'est mon cas pour IRC) les trois médias disponibles (wiki/ML/IRC). Il est donc nécessaire (mais pas forcément évident je l'accorde) que les informations soient relayées (au moins sur le wiki, puisque c'est le plus accessible et le lieu des votes). Cumuler les trois médias a certainement des avantages, mais ça présente également l'inconvénient de disperser les discussions. (Bon, je vais m'inscrire sur la liste avant de recevoir vos foudres… :P) Skippy le Grand Gourou 29 avril 2008 à 20:06 (UTC)

Chiffres en accès direct

Je fais partie de ceux qui souhaitent avoir les chiffres en accès direct, pour deux raisons qui ont certainement déjà été débattues maintes fois :

• on n'utilise que très rarement plusieurs caractères tels que "<>()_+-/* à la suite, contrairement aux chiffres ;
• dans le cadre d'une utilisation professionnelle, et contrairement à une discussion type IRC, on a très souvent recours aux nombres pour exprimer des quantités, des montants ou des dates - et dans ce cadre-là, l'utilisation du ShiftLock est malpratique.

Plutôt que de relancer le débat à ce sujet, pourrait-on avoir une variante du Bépo avec les chiffres en accès direct (« Bépo-num ») pour les irréductibles ? Kaze 1 mai 2008 à 20:33 (UTC)

Pourquoi pas ? On pourrait même en profiter pour mettre les guillemets "«" et "»" en majuscule. Tohuvabohuo 6 mai 2008 à 14:29 (UTC)

Pour ma part, ce n'est pas tant l'accès direct aux chiffres qui m'intéresse que l'accès "groupé" aux chiffres et opérateurs ()+-/*= et "." (utilisation d'un tableur). S'il faut taper une fois MAJ pour accèder à ce mode, ce n'est pas un problème et cela peut laisser l'accès direct aux signes typographiques et cela peut éviter de casser tout le travail déjà effectué Herisson 16 mai 2008 à 06:02 (UTC)

Une alternative qui me parait intéressante serait d'utiliser la touche VerrMaj (CapsLock) uniquement pour changer le comportement des chiffres : les chiffres seraient en acccès direct si VerrMaj est activé. Avantages :

• une seule disposition pour tout le monde ;
• l'activation accidentelle du VerrMaj (très courante sur les claviers classiques) aurait des conséquences limitées ;
• on peut demander à figurer sur le site CapsOff.org ;-)

Ça se fait sans problème sous Linux (voir ce fichier xkb), Glehmann et A2 me disent que c'est faisable sous MacOS™ X et Windows™ respectivement. Kaze 12 mai 2008 à 11:52 (UTC)

Touche Alt Gr symétrique

Pour l'accessibilité des AltGr + [pavé principal droit] je pense qu'on a quatre options :

1. 100% symétrique : Alt devient AltGr, avec les problèmes que ça suppose : quid du Alt, implémentation sous Windows™, etc…
2. asymétrique, en utilisant une autre touche comme AltGr (mêmes objections que précédemment)
3. asymétrique, en utilisant {Ê} comme AltGr mort (voire aussi Compose en Shift+{Ê} ?)
4. asymétrique, on ne change rien puisque les quelques caractères spéciaux dans le pavé principal droit sont très rares, du moins en français.

À titre perso je serais pour #3 ou #4 (j'utilise beaucoup Win et Alt), je ne sais pas si ça mérite d'être discuté pour la version 0.6.7. Je me suis permis de regrouper ci-dessous les propositions qui nécessitent un AltGr symétrique. Kaze 15 mai 2008 à 12:02 (UTC)

Si l'on accepte un Alt Gr symétrique :

• supprimer « ñ » et « Ñ » et déplacer le tilde mort en Alt Gr + {N},
• déplacer « ç » en Alt Gr + {C} et « Ç » en Shift + Alt Gr + {C},
• déplacer « w » en Alt Gr + {V} et « W » en Shift + Alt Gr + {V}.

Tohuvabohuo 15 mai 2008 à 12:16 (UTC)

Le « w » en Alt Gr + {V} est handicapant pour ceux pratiquant l'anglais assidument et par ailleurs il y a la proposition d'améliorer l'accès au W … points contradictoires. Herisson 16 mai 2008 à 19:19 (UTC)

Tirets cadratin et demi-cadratin sur {1}

Une autre modification pour la cohérence de la dispo :

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

• le demi-cadratin passe en Shift+AltGr+1
• le signe ¬ est remplacé par ≠ et passe en AltGr+8

Peu d'impact, mais meilleure accessibilité du demi-cadratin pour ceux qui l'utilisent, et un peu moins de chances de le confondre avec le tiret. Kaze 14 mai 2008 à 19:50 (UTC)

Le – (tiret demi cadratin) avec le — (tiret cadratin) est une bonne idée. Le ¬ est-il vraiment utilisé ? Il serait plus logique de mettre le − mathématique en alt-gr 6 et de déplacer ¬ je ne sais où.

Pour en revenir à — et – ils ne seraient pas plus accessible en 6 comme proposé pour la 0.6.6 ? Cela revient à comparer un accès direct en 6 à un accès en alt-gr en 1…

Je vois plutôt le @ à la place du % et le % en shift ou le @ en alt-gr + 1Tiot 15 mai 2008 à 08:40 (UTC)

Le ¬ pourrait être utilisé par les logiciens, mais vu que les autres symboles de logique ne sont pas sur le clavier, je ne vois pas trop ce que ce symbole fait ici. Peut-être a-t-il une autre utilité ? --Aldoo 15 mai 2008 à 12:46 (UTC)

Le ¬ est le seul signe logique qui soit présent sur d'autres dispositions standard, comme le Qwerty international et le Qwerty espagnol ; de là à savoir pourquoi… Comme il faut remplir cette case pour laisser la minute (′) en Shift+AltGr (cohérence avec la seconde), ça me parait le signe le plus approprié pour aller en AltGr+{-}.

Je n'avais jamais entendu parler du − mathématique avant. Kaze 15 mai 2008 à 21:49 (UTC)

Le - mathématique est en alt-gr + - du pavé numérique, voir signe moins (wp) pour la différence avec le trait d'union. Je ne sais pas si il est beaucoup utilisé mais il va avec les ÷ et ×. Tiot 16 mai 2008 à 06:50 (UTC)

Ce point devrait finalement être tranché par le second tour de la version 0.6.6. Le signe « - » mathématique est effectivement plus cohérent que ¬ sur le 8. Kaze 17 mai 2008 à 18:30 (UTC)

Inquiétude

J’ai voté pour que nous ne figions pas la version 0.6.6 dès sa sortie car je trouvait logique qu’un version soit testée et éprouvée avant de figer quoi que ce soit. Logique aussi qu’y soient faites des petites correction selon un cycle de RC. Ce vote n’allait donc pas contre la volonté que je croyais commune de figer le bépo. Pourtant lisant cette page je regrette mon vote. Les modifications proposée ici ne sont pas rien (double AltGr, touche compose, j’attends que les chiffres en direct arrivent…). Avec de telles perspectives, la v. 0.6.6 ne sera pas figée. De même cette version 0.6.7, si le double AltGr passe par exemple, ne sera pas « figable » et à ce rythme là j’ai peur qu’aucune la suivant ne le soit. Or toutes ces discussions récurrentes mes semblent de belles impasses puisque nous nous heurtons toujours aux mêmes sempiternels problèmes : corpus, carte d’accessibilité, types d’usages du bépo, historique des inversions… tout ce que la v2 se propose de régler, mais qui ne peut être résolu dans le cycle actuel. Je ne dis pas que les idées présentes ici soient mauvaises (quoi que, « W » en AltGr ???), ni qu’elles ne pourraient pas passer (mystères de la démocratie) mais je crois que ce n’est pas souhaitable.

Je propose donc au vote que cette 0.6.7 soit une 1.0-rc et que les seuls modifications proposées soient des corrections raisonables de la 0.6.6.passer Nemolivier 12 mai 2008 à 20:16 (UTC)

Je m'étais jusque là abstenu de voter, étant un utilisateur trop récent. Mais là je pense que je voterai pour figer la 0.6.6. La raison n'est pas que je trouve cette disposition parfaite, mais qu'on en est arrivé à un point où la plupart des défauts évidents (et corrigibles sans grosse modif) ont été corrigés (il en reste bien quelques uns, comme l'inversion ;/?) et où les seuls vrais défauts qui n'ont pas été corrigés sont ceux dont la résolution mettraient le boxon (les ZWMÇ hors de la zone principale, les chiffres en shift, les guillemets pas en shift). Or, qui dit boxon dit perte des bénéfices de l'algorithme qui avait calculé la disposition d'origine, et pléthore de nouveaux défauts auxquels on n'avait pas pensé, et qui vont nous forcer à créer encore 36 000 versions pour les corriger. Bref si on ouvre la boîte de Pandore, le projet n'aboutira jamais.

De plus, tous ces ajustements obtenus dans la douleur ces dernières années constituent de toute façon un frein psychologique à l'innovation, et il est normal que de bonnes idées trop novatrices se voient refusées dans l'état actuel du projet (du moins tant que le système du vote majoritaire perdurera). Bref les votes sur des évolutions de la disposition actuelle seront nécessairement biaisés en ce sens.

Si on veut réellement progresser, tout en gardant ce mode de fonctionnement démocratique, il n'y a pas d'autre choix que de repartir sur une nouvelle base qui évoluera parallèlement à la première base sans la casser.

C'est pour cela que je pense, comme Nemolivier, que la 0.6.6 doit être figée pour devenir une 1.0-alpha (ou bien beta ou bien rc1... selon la sémantique et l'ampleur des changements envisagés avant la 1.0). Ne pourront être modifiés pour la version suivante que des touches en shift (et inférieurs), puis celle d'après que les touches en alt-gr, et ainsi de suite, jusqu'à obtenir la 1.0 qui sera envoyée à TypeMatrix, par exemple (en revanche, normaliser la 1.0, c'est faire une croix sur la 2.0), et constituera de toute façon un argument de poids pour faire venir de nouveaux utilisateurs.

Les corrections novatrices, chamboulatoires et/ou boxogènes ne devraient être prises en compte qu'en tant que nouvelles contraintes pour l'algo qu'on fera tourner à nouveau pour obtenir une base pour la 2.0 (comment faut-il appeler la version obtenue à la sortie de l'algo ?). Comme ça, on ne casse rien, et on cherche l'optimalité sans a priori.

--Aldoo 13 mai 2008 à 09:08 (UTC)

Pour ! Asr

Je suis favorable à la sortie prochaine d'une version 1.0, mais pas avant la résolution des gros problèmes.

La mauvaise accessibilité du W est un problème qui a été soulevé par des personnes qui tapent aussi en anglais ou en allemand. À condition d'avoir un Alt Gr symétrique, Alt Gr + V m'a paru assez facile à retenir et (dites-moi si je me trompe) plus accessible qu'à l'extrême droite du clavier.

Si je me souviens bien, A2 a dit sur IRC que ça ne le choquait pas. Personne d'autre n'a réagi. J'ai donc ajouté cette proposition sur la présente page.

L'accès peu aisé aux chiffres lorsqu'on a beaucoup de grand nombres à taper et qu'on n'a pas de pavé numérique à sa disposition est un autre problème qui se pose souvent.

J'ai proposé de les rendre accessibles par la touche Caps Lock, et ça a été accepté. Mais certains trouvent ce comportement de la touche Caps Lock inadéquat.

Je pense donc qu'il faudrait faire des propositions pour avoir les chiffres en accès direct.

Optionnellement, ça permettrait de mettre les guillemets "«" et "»" en accès Shift.

Il y a certainement d'autres problèmes à résoudre, et j'apprécierais qu'ils le soient avant la version 1.0.

Ça fait trois ans que le projet est en route, alors quelques mois, voire deux ans, de plus ne me font pas peur. Rome ne s'est pas faite en un jour.

Tohuvabohuo 13 mai 2008 à 09:58 (UTC)

Figer la 0.6.6 alors qu'elle n'est même pas finie, et au risque d'incohérences ? Et ensuite prétendre à une version « stable » dans ces conditions ? Personnellement je pense qu'il vaudrait mieux se mettre d'accord sur une liste des points bloquants restants et figer ça plutôt que de figer le layout, en s'interdisant l'ajout de nouvelles fonctionnalités qui seront pour une v2. Exemple: La touche morte « lettre grecque » a été placée en AltGr+G. C'est très bien, mais que faire du µ actuel en Shift+% ? Le garder ? Le remplacer par autre chose ? C'est un problème qui est apparu suite à l'implémentation d'une nouvelle fonctionnalité. Figer le layout à ce point ne me semble pas bon, ça interdirait de mettre quelquechose comme (par exemple) l'accent grave ASCII ` en Shift+%. Par contre figer les derniers points bloquants et interdire de nouvelles fonctionnalités permettrait :

• D'éliminer la quasi-totalité des propositions sur cette page (et tant pis pour le s long ſ ou la phonétique, cf v2) ;
• De résoudre les derniers petits soucis comme le grave ASCII ` qui est passé en AltGr-Shift alors qu'il est très utile en shell ;
• D'attirer l'attention et de focaliser les efforts sur une version 2 pour ceux qui veulent ajouter des fonctionnalités.

Il faut juste se mettre d'accord sur les points à résoudre. La page des points bloquants actuels peut servir de base de départ, y compris pour reporter des changements comme W ou Ç à une version 2. Nbrodu 13 mai 2008 à 10:04 (UTC)

Tu as beaucoup de points bloquant qui sont là uniquement pour le support des langues étrangère et l'informatique. Or le Bépo v1 a été conçu pour le Français (si je ne me trompe pas) et le rendre plus international ou plus technique pourra être justement un des objectifs de la v2.Tiot 13 mai 2008 à 10:58 (UTC)

Bah, là il est en train de devenir moins technique, et plus international (cf inversion accent grave mort). C'est ce genre de compromis qui à mon avis ne peut être résolu que de façon globale. Donc oui, tu as raison que c'est un des objectifs pour une version 2. Nbrodu 13 mai 2008 à 11:17 (UTC)

AMHA, l'ajout d'une touche morte (pour la phonétique), ou d'un ſ en (shift-)alt-gr ne remet pas nécessairement en cause toute la disposition, et pourrait être fait même après la première fixation de celle-ci. Sinon je suis d'accord pour permettre la résolution les points bloquants non-chamboulatoires après la première fixation (exemple, inverser ' et ‘, si c'est souhaitable). En revanche, les chiffres en direct et l'internationalisation me semblent avoir trop de conséquences. --Aldoo 13 mai 2008 à 12:18 (UTC)

Pour éliminer quelques de points de cette page il y aurait un autre critère bien simple : qu'on retire des objectifs de la v1.0 tout ce qui ne peut pas être implémenté proprement sur toutes les plate-formes : les touches mortes non prévues par xkb, la deuxième touche AltGr, Compose, etc… Quitte à faire une version stable, faisons en sorte qu'elle soit simple. Kaze 13 mai 2008 à 15:48 (UTC)

Feuille de route

Sinon, pour la suite, pourquoi ne pas se mettre d'accord sur une feuille de route pour la version 1.0 avec des jalons à objectifs précis ? (J0 : définition des points bloquants, avec vote, J1 : résolution des points bloquants, J2 : fixation des accès directs, J3 : fixation des shift... and so on, sachant qu'il peut y avoir zéro, une ou plusieurs versions entre chaque jalon). Je propose que le prochain vote concerne la feuille de route, plutôt que le contenu de la 0.6.7. --Aldoo 13 mai 2008 à 12:27 (UTC)

+1, je pense qu'il est préférable de figer la dispo en (au moins) trois temps :

1. Carte des touches en accès direct : on évacue définitivement les souhaits et regrets sur le placement des touches de base.
2. Carte simplifiée : on fige la couche Maj et les principaux caractères en AltGr (les deux points sont liés), les propositions relatives aux accès directs étant désormais irrecevables.
3. Carte complète : on place les accès AltGr restants, les propositions impactant la carte simplifiée étant irrecevables.

Pour accélérer un peu le mouvement et pour éviter l'aspect « usine à gaz », je pense qu'on pourrait même publier une version 1.0 dès l'étape 2, avec une couche AltGr volontairement incomplète (VoidSymbol) : si la dispo contient tous les caractères présents sur les claviers type Azerty, c'est qu'elle est utilisable au quotidien. Par la suite, rien n'empêcherait de proposer des version 1.0.x où on ne s'autorise à modifier que ce qui n'impacte pas la carte simplifiée ; la « vraie » version stable serait la 1.0 et non la 1.0.x. Kazé 13 mai 2008 à 15:21 (UTC)

PS : la roadmap pourrait être accompagnée de la liste des objectifs pour les deux versions (v1 et v2), ça ne ferait pas de mal. Kaze 13 mai 2008 à 15:25 (UTC)

Texte repris depuis une discussion qui avait lieu à l'occasion du second tour de la 0.6.6, mais qui a été ajournée au vote qui aura lieu après la sortie de la version 0.6.6 pour savoir si on fige ou non les caractères (et lesquels). À mettre en forme et à fusionner avec le texte précédent.

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)

Je sais que je n'aurais peut-être pas dû faire une page à part, mais j'ai une proposition là qui il me semble s'attaque à ces problèmes, il me semble qu'il faudrait discuter de ça avant de voir les nouvelles propositions, ne serait-ce que parce que l'on ne fera pas forcément la même 0.6.7 (si on l'appelle comme ça) selon ce qu'on décide. Venez discuter du déroulement et du figeage éventuel. Galbolle 3 juin 2008 à 12:01 (CEST)

Puis une fois cette section faite (TODO)

Approuvez-vous la feuille de route ci-dessus ?

• oui
• non

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

Votez pour ou contre les propositions suivantes en fonction de vos préférences :

• 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 ?

Rappel: Un vote sera organisé après la sortie de la version 0.6.6 pour savoir si on fige ou non ces caractères

Faire de la place

Pour faire de la place sur la disposition (idées de Schultz et de Kaze publiées avec 42 jours de retard) :

• Déplacer « X » sur compose + \ + /
• Déplacer « K » sur compose + | + <
• Déplacer « ^ » sur compose + ´ + `
• Déplacer « A » sur compose + / + - + \
• Déplacer « E » sur compose + | + ¯ + _ + -
• Déplacer « F » sur compose + | + ¯ + -
• Déplacer « C » sur compose + (
• Déplacer « D » sur compose + | + )
• supprimer les minuscules, voire les lettres tout court

… Pas de vote contre SVP Tohuvabohuo 13 mai 2008 à 07:57 (UTC)