By the way, I created a draft for a policy on "calling votes", which includes these details. I can send it in a few hours.
2017-05-17 22:50 GMT+02:00 Milos Rancic <[email protected]>: > OK. Here is, first, my initial email. I will resend relevant > communication afterwards: > > == Voting == > > This is also proposal, so read it and comment if you don't agree or > you want any addition. > > 1) No voting > > 1.1) According to the Closing projects policy [1], particular member > of the committee analyzes discussion and, if decides that the project > should be closed, sends the request to WMF Board. > > 1.2) Clear-cut situations for making a language eligible for Wikimedia > projects: the language has a valid ISO 639-3 code, there are no > significant issues in relation to the language itself, the population > of speakers is significant, request made by a native speaker. In this > case, any committee member can mark language / project eligible. > > 1.3) Approval without obvious formal requirements. No project will be > approved without them. > > 2) Simple majority (of those who expressed opinion) > > 2.1) Eligibility of a language with a valid ISO 639-3 code, but > without significant population of native speakers. (Note: this covers > ancient, constructed, reviving and languages with small number of > speakers.) > > 2.2) Eligibility of a language without a valid ISO 639-3 code, but > valid BCP 47 code. (Note: this covers Ecuadorian Quechua.) > > 2.3) Eligibility of a language with significant collision between > prescriptive and descriptive information. (Note: this covers > "macrolangauges".) > > 2.4) Project approval if not 1.3. > > 3) 2/3 majority (of those who expressed opinion) > > 3.1) Any change of the rules, including the committee's role in > possible changes of the Language proposal policy [2] and Closing > projects policy [1]. > > 4) Consensus (of those who expressed opinion) > > 4.1) A new member of the Language committee should not be opposed by > any of the current committee member. > > [1] https://meta.wikimedia.org/wiki/Closing_projects_policy > [2] https://meta.wikimedia.org/wiki/Meta:Language_proposal_policy > > > On Wed, May 17, 2017 at 10:48 PM, Oliver Stegen <[email protected]> > wrote: > > The first email that I can see only contains sections 1.2, 1.3 and 2.2, > i.e. > > it looks like substantial parts of the proposal are missing. Please > upload > > the entire proposal somewhere and send the link. Thanks. > > > > > > > > On 17-May-17 22:43, Milos Rancic wrote: > >> > >> Oliver, are you able to see the first email in the thread? > >> > >> On Wed, May 17, 2017 at 10:40 PM, Oliver Stegen <[email protected]> > >> wrote: > >>> > >>> Imho, it would be helpful to have a link to the amended proposal, > rather > >>> than having to wade through previous discussion. Possible to upload and > >>> send > >>> such a link? > >>> (Or maybe that has already happened and I just can't find the link? In > >>> which > >>> case sorry for not finding it - please still send it to this list.) > >>> > >>> > >>> > >>> On 17-May-17 20:33, Milos Rancic wrote: > >>>> > >>>> We should start finishing this issue. May all of you check the > >>>> previous discussion and say if you agree in general with the proposal > >>>> amended by MF-Warburg? If so, I would make the next draft. > >>>> > >>>> On Sun, Feb 12, 2017 at 12:52 PM, Milos Rancic <[email protected]> > >>>> wrote: > >>>>> > >>>>> On Sat, Feb 11, 2017 at 6:19 PM, MF-Warburg < > [email protected]> > >>>>> wrote: > >>>>>>> > >>>>>>> 1.2) Clear-cut situations for making a language eligible for > >>>>>>> Wikimedia > >>>>>>> projects: the language has a valid ISO 639-3 code, there are no > >>>>>>> significant issues in relation to the language itself, the > population > >>>>>>> of speakers is significant, request made by a native speaker. In > this > >>>>>>> case, any committee member can mark language / project eligible. > >>>>>> > >>>>>> This is already what we are doing. But if such a case should turn > out > >>>>>> to > >>>>>> be > >>>>>> contentious, we would discuss it even after someone marked it as > >>>>>> eligible > >>>>>> without discussion. At least that would have been my expectation. So > >>>>>> if > >>>>>> we > >>>>>> want to make such a detailed policy, could we please add that as > well? > >>>>> > >>>>> Agreed. > >>>>> > >>>>>>> 1.3) Approval without obvious formal requirements. No project will > be > >>>>>>> approved without them. > >>>>>> > >>>>>> What does this mean exactly? > >>>>> > >>>>> Yes, it could be described more in detail. I thought that we can't > >>>>> vote about approving a new Wikipedia if they didn't translate 500 > >>>>> MediaWiki messages and similar. I was too lazy to take a look into > the > >>>>> exact conditions for approval. In other words, we could discuss about > >>>>> the activity, but we can't discuss to approve the project if it's not > >>>>> written in particular language. And similar. > >>>>> > >>>>>> Ok, this is our current issue with Lingua Franca Nova and Ancient > >>>>>> Greek. > >>>>>> Shouldn't we better discuss about the underlying policy regarding > >>>>>> constructed and ancient languages? A general rule seems better than > >>>>>> the > >>>>>> possibility to allow everything by a majority vote. > >>>>> > >>>>> Yes. But it would anyway require majority vote. What's the difference > >>>>> between Ancient Greek and Sumerian? Would we allow Wikipedia in > >>>>> Sumerian? Classical Hebrew? ... > >>>>> > >>>>>>> 2.2) Eligibility of a language without a valid ISO 639-3 code, but > >>>>>>> valid BCP 47 code. (Note: this covers Ecuadorian Quechua.) > >>>>>> > >>>>>> I don't recall that we ever discussed allowing projects with BCP47 > >>>>>> codes. > >>>>>> Again, isn't this something that should be discussed as a policy? > >>>>> > >>>>> In general, we should discuss and (hopefully) approve usage BCP 47 > >>>>> formally, as well. However, it is so wide territory, that it's hard > to > >>>>> make a consistent rule about it: Why should we approve qu-ec and why > >>>>> we shouldn't approve en-au? Why it's better to use mn-mong for > >>>>> Mongolian instead of mvf? ... > >>>>> > >>>>>> The combination of 3.1 and 4.1 would be bad insofar as it allows a > 2/3 > >>>>>> majority to introduce a new member anyway. > >>>>> > >>>>> Yes. But that would mean that there is something really bad going on > >>>>> here. > >>>>> > >>>>>> Yes, Langcom works with the principle that a proposal is approved > >>>>>> unless > >>>>>> a > >>>>>> member is against it, in which case the proposal dies (it is not > >>>>>> exactly > >>>>>> rejected, n'est-ce pas?). > >>>>>> At times I have been quite annoyed by it as well. I think however > that > >>>>>> in > >>>>>> general it works quite well. Over the course of the years in which I > >>>>>> have > >>>>>> been a langcom member now, I sometimes thought about whether the > >>>>>> “governance“ could be improved. But my personal conclusion always > was: > >>>>>> not > >>>>>> really. It wouldn't harm to formalize a rule for getting rid of a > >>>>>> theoretical trollish member opposing everything without a reason. > But > >>>>>> apart > >>>>>> from that? I'm not really sure that introducing majority voting will > >>>>>> help > >>>>>> much. > >>>>> > >>>>> Time and efforts required for arguing with only one person and having > >>>>> in mind that it's useless makes LangCom dysfunctional. Besides that, > >>>>> in few years we could have even 100 requests for eligibility per > year. > >>>>> It's likely that 60-70 would be valid, but it's also likely that we > >>>>> would have to spend extraordinary time on discussion about 10-20 of > >>>>> them. Even if it's once per month, it would be stressful enough and > >>>>> lead us into the new period of hibernation. > >>>>> > >>>>> Besides that, it's not about random persons here, but about people > >>>>> with enough professional and personal integrity. It is normal that we > >>>>> don't agree about everything and that we should accept if more > members > >>>>> of LangCom decided to approve the project. > >>>> > >>>> _______________________________________________ > >>>> Langcom mailing list > >>>> [email protected] > >>>> https://lists.wikimedia.org/mailman/listinfo/langcom > >>>> > >>>> > >>>> --- > >>>> This email has been checked for viruses by AVG. > >>>> http://www.avg.com > >>> > >>> > >>> > >>> _______________________________________________ > >>> Langcom mailing list > >>> [email protected] > >>> https://lists.wikimedia.org/mailman/listinfo/langcom > >> > >> _______________________________________________ > >> Langcom mailing list > >> [email protected] > >> https://lists.wikimedia.org/mailman/listinfo/langcom > > > > > > > > _______________________________________________ > > Langcom mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/langcom > > _______________________________________________ > Langcom mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/langcom >
_______________________________________________ Langcom mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/langcom
