Received: from mail-vk0-f61.google.com ([209.85.213.61]:55011) by stodi.digitalkingdom.org with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eOK2q-00012w-9F for lojban-list-archive@lojban.org; Mon, 11 Dec 2017 01:06:44 -0800 Received: by mail-vk0-f61.google.com with SMTP id p80sf9171466vkd.21 for ; Mon, 11 Dec 2017 01:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=uZOGe6b330YGILW3CN3ewqdGG+AykqaSp1eCqZZaPvg=; b=oMywr4DZCV3aV8AkBSKPa7KfTNeedpBLbMRVpZcDVs+JIB4YNxDBv1YVJww6r5bg4D e3oUY+z2jnTrnzcSpzNp+ID49eVpwkEyMYBPTcvXIT7XU0Q2NXKw6jckqzWqelwwzJnY 1OeRdM4auKPTUnhnuwqtfPaLrCSHbjfAfhiEwtx189OYpnQ/KfIFMnucCWbPRfDWQ95j GMMWnc4+vneXC3899XlcfWMtLBtp+Elp4mgRdUTKcpGtqJi6HI9VlL4FeJaGlR6isv8R bj/FxhwOoljmzuaQI5nNl3cOtjEbfuG1yWXewc/P1UwBsaYhLU4fdf/sL7t047+YaZwX d+Pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=uZOGe6b330YGILW3CN3ewqdGG+AykqaSp1eCqZZaPvg=; b=gTurgVoxzJkwWP9F2XeH3aPtrAYZccr0XAeZuk/Pbv9mChu1O8LsyJUSizg3q3SDbT gKkNYQMA84RyHEzWpJGQQDucLRgF6THq/wxKkfGhwf1Q6eQZFG+bb5rYcjkgFOsXucEk y0I4bloNSjZsMNIgS2JdGHLCUfPgOU/4yJDEtdGZjKjxgyJDN3WSAbHc6RNNf5qfQKbF mk4ATIxUszDCRZ2Qbu5ySAFcSQKWELuHT7nSnXM/PwVTV2DSxR3hu//ec9idLJBYK+X0 lQ1uPjiH7h6igcF/kRyNQQkcnZ5vdFk4kGTxfIKUiTU/5zU8Ow62GWB+vadkg4ENoyC0 5NYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=uZOGe6b330YGILW3CN3ewqdGG+AykqaSp1eCqZZaPvg=; b=ggOGbANxRAlQfFZkTV5D5hZ3+WmaxGSDJMZ4O5QkylY/bFZvZ42zp9IAjVyfr9nFQX yt7AEmlCM/7OOWK+irxuX444UCMgevqRF39RA2tQO2aR0uzxatu1ySjiL6538j79EN1n LG4babKmxlu5A+iIkL21q8TWbnw7ID4MmjS0RYXuBEwJuXkmKgoo9YTF/5T54ILKecAs 9pbtRYe5au4w2H0z8TRmTa6cPHwUabQCzXS4PH/JIL58eO5htRu4B8KIrqCq/d8YDHVO P1KlUb3ex0DQBLGMz23Lb2sS7B+K8fkn6rl3gtafLJugFH3gmoCg52nA+QoDUSASC5ne KX/w== Sender: lojban@googlegroups.com X-Gm-Message-State: AKGB3mIxnOT8avciuP2VRMQDUnSgJRv9N7mGzpQZDM+3vaGWlDzWJ9/P Fo8VXQB9+JIP4B22pN1YERo= X-Google-Smtp-Source: AGs4zMZ9RuOkUxa5O4iVrBrj/8Fkm9ebK4t/KvdALgnRLcILp1jWrwYq/d+oXvaQSa12RegJcx1G8A== X-Received: by 10.31.174.75 with SMTP id x72mr2128210vke.13.1512983190298; Mon, 11 Dec 2017 01:06:30 -0800 (PST) X-BeenThere: lojban@googlegroups.com Received: by 10.31.167.69 with SMTP id q66ls2554336vke.13.gmail; Mon, 11 Dec 2017 01:06:29 -0800 (PST) X-Received: by 10.31.148.200 with SMTP id w191mr2124368vkd.11.1512983189355; Mon, 11 Dec 2017 01:06:29 -0800 (PST) Date: Mon, 11 Dec 2017 01:06:29 -0800 (PST) From: sukender1@gmail.com To: lojban Message-Id: <9e82108b-4c96-4641-89bd-0d1d6c503cf3@googlegroups.com> In-Reply-To: <075de629-bf47-4736-bc25-ccf4c953d2a8@googlegroups.com> References: <963393d6-a9f1-4232-be13-b4ee76eb69e1@googlegroups.com> <7d063690-0550-45d6-9779-3334ac8e17b5@googlegroups.com> <4aefe693-e504-4518-09e5-d82a360c333c@posteo.net> <322158ae-e6ad-49b0-9dba-0dddf71609f1@googlegroups.com> <075de629-bf47-4736-bc25-ccf4c953d2a8@googlegroups.com> Subject: Re: [lojban] Re: CLL and modern Lojban MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7047_1417425202.1512983189103" X-Original-Sender: sukender1@gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: lojban@googlegroups.com X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.8 (-) X-Spam_score: -1.8 X-Spam_score_int: -17 X-Spam_bar: - ------=_Part_7047_1417425202.1512983189103 Content-Type: multipart/alternative; boundary="----=_Part_7048_601534940.1512983189104" ------=_Part_7048_601534940.1512983189104 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable coi (*I'm making some progress in creating a prototype for a submission system= =20 (in order to show you all, test, validate, etc.). But I have a few pending= =20 issues. I'll let you know!*) Meanwhile... *Protection against bashing and other biases* I had a discussion with someone and he told me the current system design=20 may be subject to a (small) risk of "user bashing". If someone doesn't=20 please people (for instance by saying things unrelated to Lojban, about=20 religion, politics, etc.) he/she may be unfairly "punished" by other=20 people, lowering their grade towards this user. As a result he/she may=20 quickly loose permissions even though the contribution from that user was= =20 important and his/her Lojban level is very high. Some other biases of the same kind may exist, such as the opposite behavior= =20 (a numerous group of people with no knowledge, getting over the community= =20 with unfair voting), similar to the "51% attack". Actually the risk is supposedly very low at the beginning (initial people= =20 are generally fair about each other, because very involved). Then the risk= =20 grows as newcomers arrive, but decreases with the number of users (the more= =20 users, the smaller impact each will have). So this is quite important to=20 address this issue now, in my opinion. However, I'm convinced there is no way to predict all "unfair" behaviors,= =20 and that even powerful and costly algorithms can't help us much. This is=20 why I'm relaying the solution which was proposed to me (with minor=20 adaptations): - Let N people be "guardians": - They would have the role of fighting unfair behaviors (and only=20 this role). - And they would have administrative privileges (over the system) for= =20 this: ban people, restore some permissions, etc. - Hopefully, they would almost never have to do so... - Make sure all their actions (as "guardians") are logged and=20 documented, and publicly accessible. Everyone could then ensure their ro= le=20 is respected (=3D that they do not use their permissions to tackle other= =20 topics, such as Lojban-related ones). - One user may have various roles AND a "guardian" role at the same=20 time, of course. - Maybe that would require two distinct user accounts? - Elect those "guardians" periodically (say each 6 months? 1 year?).=20 Election would use common rules: - Everyone can be candidate. - If there are less than N candidates, then missing candidates are= =20 algorithmically found (Maybe the ones with most permissions? Or si= mply=20 randomly?). - Each user can vote. - Can he/she can vote for N candidates? Or maybe just one? - The N users with most votes "win". =20 What do you think about it? la .sykyndyr. Le jeudi 23 novembre 2017 10:34:59 UTC+1, Benoit Neil a =C3=A9crit : > > @Gregorio, @all > > First of all, I thank you *A LOT* for having taken time for this detailed= =20 > answer and proposal. > > If I rephrase correctly, the first issue you point out is that the=20 > *number* of Lojbanists is too low for such a workflow. If your numbers=20 > are correct, then I agree. That's unfortunate for the proposal, but this = is=20 > exactly what I said when I answered Gleki: I'm "relying on statistics and= =20 > probability". That means the result of voting (and such) is less prone to= =20 > be far away from "the absolute truth" (whatever it is) when there are man= y=20 > people. Said otherwise, there is higher chance of having a biased result= =20 > with a limited amount of users. Question is: what is an "acceptable=20 > threshold"? I don't know. > > I propose to make a very basic implementation of the system, ask for=20 > Lojbanists to register, and check about the number of accounts. That woul= d=20 > give us a first idea of the feasibility. > > *** > > About current LLG/BPFK/Coders' Group: Well, I'm *TRYING* to propose=20 > something transversal, which could be immune/insensitive to the=20 > organization the user comes from. Of couse, that sounds quite obvious the= =20 > ones in BPFK (for instance) would receive very high "language kudos score= s"=20 > from the community. So yes, you're right about it. But the proposed syste= m=20 > would make it possible to exclude one of them (I hope this won't be the= =20 > case), and include someone from the outside (I hope there will be=20 > candidates). > > Actually, I guess you're right about saying BPFK+Robin will be the core= =20 > people. Maybe with some LLG guys in addition? > > Maybe the system would hard-code some roles (see below) in the first=20 > months/years of its existence?... To be discussed... > Maybe the system is to be administrated by one of the current organizatio= n=20 > in the future? I don't know yet. > > What I feel is that the currently missing mechanism is a clear submission= =20 > & integration workflow (hence the proposal, of course). I hope that if=20 > people agree with a "systematic" workflow, then it would help sorting out= =20 > the "semi-official" things and start a new "era". > > *** > > You also raised an interesting issue in your answer: *roles*. I propose= =20 > to add some more rules and definitions, to tackle that: > > - Define some "*roles*", which are roughly "jobs" or=20 > "responsibilities". > - Ex: Proposal validator, submission validator (=3D voting member),=20 > GitHub integrator (=3D merge pull requests), release manager, etc. = The list=20 > is to be debated. > - Relation is N-N with users: multiple users can be assigned to a= =20 > role, and each user may have multiple roles. > - As you proposed, maybe a "chair/root/super-admin/lead" role would= =20 > be to be added, with the ability to have a "super-weighted" vote=20 > if-and-only-if a voting procedure doesn't fulfill the minimum requi= rements=20 > (ex: 50% / 66.7% / N% of "yes", and a minimum of M votes). > - System would check periodically for accounts activity, to=20 > automatically un-assign inactive users. > - Ex: Each month/year/whatever, an email with a link is sent. The user= =20 > must then update its roles assignations within days/weeks, or else = (s)he is=20 > automatically unassigned. > - Each role has some requirements (language level, logic knowledge,=20 > etc.), as defined before. > - Ex: Proposal validator needs to be at least "B1". > - Each role is assigned a minimum number of people, to ensure the=20 > tasks are executed (point I mentioned in a previous post). > - Ex: There should be at least 10 "proposal validators". > - If there are not enough people to fill a role, then the "closest"= =20 > (regarding to requirements) are chosen. > - As kudos may be added/modified/removed at any time, user is notified= =20 > of new available roles, and roles un-assignations. > > Of course, this is still tied to the community size... That point induces= =20 > that the system must be worked on at the same time Lojban is promoted=20 > (maybe a coordinated "advertising campaign" will be necessary? Ex: all=20 > "users" are asked to share/post/relay a unique text to various mediums,= =20 > such as social networks?). > > la .sykyndyr. > > > Le jeudi 23 novembre 2017 01:23:36 UTC+1, Gregorio Guidi a =C3=A9crit : >> >> On 11/22/2017 09:58 AM, suke...@gmail.com wrote: >> >> Alright. Time for my v0.2 proposal about submissions. I integrated what= =20 >> Gleki and Gregorio said, from the "simplified v0.1" version.=20 >> To avoid having "actual experts" situation or the "anyone is expert"=20 >> situation, I'm proposing a balanced way. I thought about algorithms=20 >> determining the implication of each one in the Lojban project but rules= =20 >> ended to be way too complex, not taking all important aspects into=20 >> consideration, and unmaintainable. So I changed my mind and I am now=20 >> proposing a king of "merit" mechanism: >> >> - Each user can self-evaluate about the language. This is purely=20 >> informational. Grades would be (for instance): zero, A1, A2, B1, B2, = C1, C2=20 >> (as per CERF, with the addition of "zero"). >> - Level is rounded by *default* (so that "A1+" is not A2 but A1). >> - Ex: I'm pretty sure I'm "zero", because I cannot say I reached= =20 >> the A1 level.=20 >> - Each user can give "language level" kudos to anyone else, asserting= =20 >> the target is *AT LEAST* the given level. >> - Ex: I don't know much aout Gleki, but I'm 100% convinced I can give= =20 >> him B2 level. Maybe much more, but B2 is the highest level I'm 100= %=20 >> confident with.=20 >> - Given kudos can be changed at any time.=20 >> - All kudos are gathered to determine the "granting" level. If an=20 >> user gets at least "X% votes" and at least "N votes", (s)he get that = level. >> - Ex: Gleki has 2 "C1", 5 "B2", and 3 "B1".=20 >> - If we require "50% / 5 votes", then he would be B2.=20 >> - For "50% / 6 votes", he would be "B2" too (C1 count, as it is= =20 >> greater, leading to the "70% / 7 votes" B2 score).=20 >> - For "90% / 5 votes", he would be B1.=20 >> - That doesn't mean one is really "B2" for instance. That means=20 >> the community grants the rights associated with B2 level to someon= e. >> - Same thing (self-evaluate & kudos) should be applied to "logic= =20 >> knowledge", with grades from 0 to 5 (for instance). This would also b= e a=20 >> requirement to validate submissions. >> - Maybe the system can be extended to other things, such as=20 >> "technical level", and/or "general community kudos" (maybe others?). = The=20 >> level would grant access to some features, to be determined. >> =20 >> Going from that, the submission protocol can be more precise about the= =20 >> former "expert" term. In the following diagram: >> >> - "[B1]" means "the authenticated user must be granted the language= =20 >> level B1 or more". >> - "[logic 2]" means "the authenticated user must be granted the=20 >> logical level 2 or more".=20 >> - Please note that all levels (B1, C1, logic 2, etc...) are purely=20 >> arbitrary for now, and may be adapted. >> - "Technical level" kudos are not integrated in the diagram, nor=20 >> anything about who may tag versions and edit roadmaps. Your ideas are= =20 >> welcome!=20 >> - The current system *DOESN'T* ensure there is at least one person=20 >> able to validate or vote. I guess a simple rule taking "N best graded= =20 >> users" may be added. >> =20 >> >> >> >> >> @all: Your thoughts? >> >> >> Thanks a lot for the proposal! I see you are taking a clear "top-down"= =20 >> approach, imagining an organization to put on top of the existing users = and=20 >> experts within the Lojban community. I like the goal that you have in mi= nd.=20 >> What I doubt, however, is whether the approach can fit with the limited= =20 >> size of the Lojban community. >> >> I try to explain... In the end, it all comes down to who has control on= =20 >> the main resources of the project (the website, the official pages of th= e=20 >> wiki and the associated material, the lojban github account, the mailing= =20 >> lists) and how they decide to develop those resources. How many communit= y=20 >> members are candidates to fill those key roles?... How many people speak= =20 >> Lojban and are currently actively involved in the project? I don't know.= ..=20 >> maybe 10? Is it possible to build a complex structure on top of this set= of=20 >> core people that would need to fill all key parts of the workflow? Given= =20 >> the size, perhaps it would be reasonable to just check with them one by= =20 >> one, and see what they would like to do... >> >> Hoping to be constructive, I will try to elaborate more on this=20 >> "bottom-up" approach (i.e. what can be proposed on the basis of the=20 >> community as it exists now) and see what comes out of it. As a disclaime= r,=20 >> I note that the following observations come from me as an external obser= ver=20 >> of the dynamics of the Lojban community, so I apologize in advance for n= ot=20 >> being completely informed on some of the inner workings. >> >> Let us start with the main actors involved... consider the LLG. It is my= =20 >> impression that in recent years, and in particular after the BPFK=20 >> Reauthorization , the= =20 >> LLG is distancing itself somewhat from the previous role of active drive= r=20 >> of the development of the language, essentially leaving future developme= nts=20 >> in the hands of the BPFK members (while maintaining the power of approva= l=20 >> for "official standards"). From what I can see, the LLG has resources fo= r=20 >> carrying out only the bare minimum of activities: the legal duties to=20 >> continue existing as a legal entity, managing the finances and the print= ing=20 >> and distributions of the physical copies of the CLL. >> >> This situation leaves the focus mostly on the BPFK members=20 >> . If the wiki is not in error,= =20 >> they are: >> >> - la selpa'i (Chair of BPFK since March 16, 2015)=20 >> - Pierre Abbat=20 >> - la gleki=20 >> - Durka42=20 >> - Ilmen=20 >> - la .xorxes. >> - Adam D. Lopresto, aka la xalbo=20 >> - la .guskant.=20 >> - la mezohe (Joined November 17, 2015)=20 >> >> It is natural to see them as the best candidates to exert control on the= =20 >> core lojban resources. >> >> Then there is the Lojban Coder's Group. What/who is it in practice? I ca= n=20 >> see from the github pages that for the cll repository this is mostly Rob= in=20 >> Powell. Other members of the organization do not seem very active, at le= ast=20 >> in comparison. Indeed Robin almost single-handedly managed to produce=20 >> version 1.1 of the CLL with years of dedicated work, clearly a huge=20 >> accomplishment, and this was done in addition to maintaining most of the= =20 >> infrastructure (and being the previous BPFK Chair). I have the impressio= n,=20 >> though, that after 1.1 he expects that someone else will step up to the= =20 >> role (please correct me if I am wrong). >> >> Then there is the maintenance of the semi-official parsers in the=20 >> ilmentufa repository, mostly by Ilmen. Here I honestly find it difficult= to=20 >> explain the conflicts between BPFK and Coder's Group... (after all Ilmen= is=20 >> also a member of the BPFK, right?). I do not really find anything clearl= y=20 >> to blame on all sides, from a superficial perspective it seems natural t= hat=20 >> community members work on their parsers while an official fully-specifie= d=20 >> grammar and an associated parser is still not available (and this is due= =20 >> since ~15 years, I believe?). In a sense, the problem will solve itself= =20 >> once the BPFK releases an official final baseline grammar with an=20 >> associated parser. >> >> So, who should have control of the core lojban resources (wiki, github= =20 >> repositories, ...)? If I had to put down a proposal, I would say all the= =20 >> members of the BPFK plus Robin. They should be empowered to apply bugfix= es=20 >> as they see fit, and set roadmaps for future releases, while continuing = the=20 >> discussions on the more technical points. It is painful to see trivial= =20 >> bugfixes pending in pull requests with no one to pick them up. >> >> What if there is no consensus? Well, the BPFK has a formal Chair. Why no= t=20 >> having him have the final word on what goes in and goes out, when consen= sus=20 >> cannot be reached? >> >> To complete the proposal, the LLG should just acknowledge the current=20 >> dire situation. The BPFK should stop being considered as a formal commit= tee=20 >> (for some reason they always remind me of this sketch=20 >> ) and just be taken for= =20 >> what it is: a group of volunteers that is given control of some core=20 >> resources, in the hope that the group will develop them and make the Loj= ban=20 >> ecosystem better over time. The BPFK should be free to set its preferred= =20 >> direction for the project, subject to the usual pressures of open source= =20 >> communities: the threat to lose users/contributors if they are too much= =20 >> alienated, or be subject to debilitating forks. A simple way to manage= =20 >> conflicts would be to give one member the power to have the final say on= =20 >> what goes in, as said before. This would also be subject to the usual=20 >> counterbalancing pressures of open source communities. This role could b= e=20 >> seen as a sort of "lead developer" within a group of "core developers", = to=20 >> continue the analogy with software projects. Or a "release manager", as= =20 >> said in another post. >> >> Just my 2 cents... >> > --=20 You received this message because you are subscribed to the Google Groups "= lojban" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to lojban+unsubscribe@googlegroups.com. To post to this group, send email to lojban@googlegroups.com. Visit this group at https://groups.google.com/group/lojban. For more options, visit https://groups.google.com/d/optout. ------=_Part_7048_601534940.1512983189104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
coi

(I'm making some = progress in creating a prototype for a submission system (in order to show = you all, test, validate, etc.). But I have a few pending issues. I'll l= et you know!)
Meanwhile...

Protection against bashing and other biases
I had a = discussion with someone and he told me the current system design may be sub= ject to a (small) risk of "user bashing". If someone doesn't = please people (for instance by saying things unrelated to Lojban, about rel= igion, politics, etc.) he/she may be unfairly "punished" by other= people, lowering their grade towards this user. As a result he/she may qui= ckly loose permissions even though the contribution from that user was impo= rtant and his/her Lojban level is very high.
Some other biases of= the same kind may exist, such as the opposite behavior (a numerous group o= f people with no knowledge, getting over the community with unfair voting),= similar to the "51% attack".

Actually t= he risk is supposedly very low at the beginning (initial people are general= ly fair about each other, because very involved). Then the risk grows as ne= wcomers arrive, but decreases with the number of users (the more users, the= smaller impact each will have). So this is quite important to address this= issue now, in my opinion.

However, I'm convin= ced there is no way to predict all "unfair" behaviors, and that e= ven powerful and costly algorithms can't help us much. This is why I= 9;m relaying the solution which was proposed to me (with minor adaptations)= :
  • Let N people be "guardians":
    • They= would have the role of fighting unfair behaviors (and only this role).
      =
    • And they would have administrative privileges (over the system) fo= r this: ban people, restore some permissions, etc.
    • Hopefully, they = would almost never have to do so...
  • Make sure all their action= s (as "guardians") are logged and documented, and publicly access= ible. Everyone could then ensure their role is respected (=3D that they do = not use their permissions to tackle other topics, such as Lojban-related on= es).
  • One user may have various roles AND a "guardian"= role at the same time, of course.
    • Maybe that would require= two distinct user accounts?
  • Elect those "guardians"= periodically (say each 6 months? 1 year?). Election would use common rules= :
    • Everyone can be candidate.
      • If there are less = than N candidates, then missing candidates are algorithmically found (Maybe= the ones with most permissions? Or simply randomly?).
    • Each us= er can vote.
      • Can he/she can vote for N candidates? Or maybe jus= t one?
    • The N users with most votes "win".
    <= /ul>
What do you think about it?

la .syk= yndyr.



Le jeudi 23 novembre 2017 10:= 34:59 UTC+1, Benoit Neil a =C3=A9crit=C2=A0:
@Gregorio, @all

First of all, I thank you A LOT for having taken time for this det= ailed answer and proposal.

If I rephrase correctly= , the first issue you point out is that the number of Lojbanists is = too low for such a workflow. If your numbers are correct, then I agree. Tha= t's unfortunate for the proposal, but this is exactly what I said when = I answered Gleki: I'm "relying on statistics and probability"= . That means the result of voting (and such) is less prone to be far away f= rom "the absolute truth" (whatever it is) when there are many peo= ple. Said otherwise, there is higher chance of having a biased result with = a limited amount of users. Question is: what is an "acceptable thresho= ld"? I don't know.

I propose to make a ve= ry basic implementation of the system, ask for Lojbanists to register, and = check about the number of accounts. That would give us a first idea of the = feasibility.

***

About cu= rrent LLG/BPFK/Coders' Group: Well, I'm TRYING=C2=A0to propo= se something transversal, which could be immune/insensitive to the organiza= tion the user comes from. Of couse, that sounds quite obvious the ones in B= PFK (for instance) would receive very high "language kudos scores"= ; from the community. So yes, you're right about it. But the proposed s= ystem would make it possible to exclude one of them (I hope this won't = be the case), and include someone from the outside (I hope there will be ca= ndidates).

Actually, I guess you're right abou= t saying BPFK+Robin will be the core people. Maybe with some LLG guys in ad= dition?

Maybe the system would hard-code some role= s (see below) in the first months/years of its existence?... To be discusse= d...
Maybe the system is to be administrated by one of the curren= t organization in the future? I don't know yet.

What I feel is that the currently missing mechanism is a clear submission= & integration workflow (hence the proposal, of course). I hope that if= people agree with a "systematic" workflow, then it would help so= rting out the "semi-official" things and start a new "era&qu= ot;.

***

You also raised = an interesting issue in your answer: roles. I propose to add = some more rules and definitions, to tackle that:
  • Define s= ome "roles", which are roughly "jobs" or "r= esponsibilities".
    • Ex: Proposal validator, submission v= alidator (=3D voting member), GitHub integrator (=3D merge pull requests), = release manager, etc. The list is to be debated.
    • Relation is N-N wi= th users: multiple users can be assigned to a role, and each user may have = multiple roles.
    • As you proposed, maybe a "chair/root/super-adm= in/lead" role would be to be added, with the ability to have a "s= uper-weighted" vote if-and-only-if a voting procedure doesn't fulf= ill the minimum requirements (ex: 50% / 66.7% / N% of "yes", and = a minimum of M votes).
  • System would check periodically for acc= ounts activity, to automatically un-assign inactive users.
    • = Ex: Each month/year/whatever, an email with a link is sent. The user must t= hen update its roles assignations within days/weeks, or else (s)he is autom= atically unassigned.
  • Each role has some requirements (language= level, logic knowledge, etc.), as defined before.
    • Ex: Prop= osal validator needs to be at least "B1".
  • Each role = is assigned a minimum number of people, to ensure the tasks are executed (p= oint I mentioned in a previous post).
    • Ex: There should be a= t least 10 "proposal validators".
    • If there are not enough= people to fill a role, then the "closest" (regarding to requirem= ents) are chosen.
  • As kudos may be added/modified/removed at an= y time, user is notified of new available roles, and roles un-assignations.=
Of course, this is still tied to the community size...= That point induces that the system must be worked on at the same time Lojb= an is promoted (maybe a coordinated "advertising campaign" will b= e necessary? Ex: all "users" are asked to share/post/relay a uniq= ue text to various mediums, such as social networks?).

=
la .sykyndyr.


Le jeudi 23 novembre 2017 01:23:= 36 UTC+1, Gregorio Guidi a =C3=A9crit=C2=A0:
=20 =20 =20
On 11/22/2017 09:58 AM, suke...@gmail.com wrote:
Alright. Time for my v0.2 proposal about submissions. I integrated what Gleki and=C2=A0Gregorio=C2=A0said,= from the "simplified v0.1" version.
To avoid having "actual experts" situation or the &q= uot;anyone is expert" situation, I'm proposing a balanced way. I th= ought about algorithms determining the implication of each one in the Lojban project but rules ended to be way too complex, not taking all important aspects into consideration, and unmaintainable. So I changed my mind and I am now proposing a king of "merit" mechanism:
  • Each user can self-evaluate about the language. This is purely informational. Grades would be (for instance): zero, A1, A2, B1, B2, C1, C2 (as per CERF, with the addition of "zero").
    • Level is rounded by default (so that "A1+&quo= t; is not A2 but A1).
    • Ex: I'm pretty sure I'm "zero", because= I cannot say I reached the A1 level.
  • Each user can give "language level" kudos to anyo= ne else, asserting the target is AT LEAST the given level.
    • Ex: I don't know much aout Gleki, but I'm 100% convinced I can give him B2 level. Maybe much more, but B2 is the highest level I'm 100% confident with.
    • Given kudos can be changed at any time.
  • All kudos are gathered to determine the "granting"= ; level. If an user gets at least "X% votes" and at l= east "N votes", (s)he get that level.
    • Ex: Gleki has 2 "C1", 5 "B2", and 3 &= quot;B1".
      • If we require "50% / 5 votes", then he would = be B2.
      • For "50% / 6 votes", he would be "B2&quo= t; too (C1 count, as it is greater, leading to the "70% / 7 votes"= ; B2 score).
      • For "90% / 5 votes", he would be B1.
    • That doesn't mean one is really "B2" for in= stance. That means the community grants the rights associated with B2 level to someone.
  • Same thing (self-evaluate & kudos) should be applied to "logic knowledge", with grades from 0 to 5 (for instance). This would also be a requirement to validate submissions.
  • Maybe the system can be extended to other things, such as "technical level", and/or "general communit= y kudos" (maybe others?). The level would grant access to some features, to be determined.
Going from that, the submission protocol can be more precise about the former "expert" term. In the followin= g diagram:
  • "[B1]" means "the authenticated user must be= granted the language level B1 or more".
  • "[logic 2]" means "the authenticated user mu= st be granted the logical level 2 or more".
  • Please note that all levels (B1, C1, logic 2, etc...) are purely arbitrary for now, and may be adapted.
  • "Technical level" kudos are not integrated in the diagram, nor anything about who may tag versions and edit roadmaps. Your ideas are welcome!
  • The current system DOESN'T ensure there is at least one person able to validate or vote. I guess a simple rule taking "N best graded users" may be add= ed.



@all: Your thoughts?

Thanks a lot for the proposal! I see you are taking a clear "top-down" approach, imagining an organization to put on top = of the existing users and experts within the Lojban community. I like the goal that you have in mind. What I doubt, however, is whether the approach can fit with the limited size of the Lojban community.

I try to explain... In the end, it all comes down to who has control on the main resources of the project (the website, the official pages of the wiki and the associated material, the lojban github account, the mailing lists) and how they decide to develop those resources. How many community members are candidates to fill those key roles?... How many people speak Lojban and are currently actively involved in the project? I don't know... maybe 10? Is it possible to build a complex structure on top of this set of core people that would need to fill all key parts of the workflow? Given the size, perhaps it would be reasonable to just check with them one by one, and see what they would like to do...

Hoping to be constructive, I will try to elaborate more on this "bottom-up" approach (i.e. what can be proposed on the basis = of the community as it exists now) and see what comes out of it. As a disclaimer, I note that the following observations come from me as an external observer of the dynamics of the Lojban community, so I apologize in advance for not being completely informed on some of the inner workings.

Let us start with the main actors involved... consider the LLG. It is my impression that in recent years, and in particular after the BPFK Reauthorization, the LLG is distancing itself somewhat from the previous role of active driver of the development of the language, essentially leaving future developments in the hands of the BPFK members (while maintaining the power of approval for "official standards"). From what I can see, the LLG has resou= rces for carrying out only the bare minimum of activities: the legal duties to continue existing as a legal entity, managing the finances and the printing and distributions of the physical copies of the CLL.

This situation leaves the focus mostly on the BPFK members. If the wiki is not in error, they are:
  • la selpa'i (Chair of BPFK since March 16, 2015)
  • Pierre Abbat
  • la gleki
  • Durka42
  • Ilmen
  • la .xorxes.
  • Adam D. Lopresto, aka la xalbo
  • la .guskant.
  • la mezohe (Joined November 17, 2015)
It is natural to see them as the best candidates to exert control on the core lojban resources.

Then there is the Lojban Coder's Group. What/who is it in practice? I can see from the github pages that for the cll repository this is mostly Robin Powell. Other members of the organization do not seem very active, at least in comparison. Indeed Robin almost single-handedly managed to produce version 1.1 of the CLL with years of dedicated work, clearly a huge accomplishment, and this was done in addition to maintaining most of the infrastructure (and being the previous BPFK Chair). I have the impression, though, that after 1.1 he expects that someone else will step up to the role (please correct me if I am wrong).

Then there is the maintenance of the semi-official parsers in the ilmentufa repository, mostly by Ilmen. Here I honestly find it difficult to explain the conflicts between BPFK and Coder's Group..= . (after all Ilmen is also a member of the BPFK, right?). I do not really find anything clearly to blame on all sides, from a superficial perspective it seems natural that community members work on their parsers while an official fully-specified grammar and an associated parser is still not available (and this is due since ~15 years, I believe?). In a sense, the problem will solve itself once the BPFK releases an official final baseline grammar with an associated parser.

So, who should have control of the core lojban resources (wiki, github repositories, ...)? If I had to put down a proposal, I would say all the members of the BPFK plus Robin. They should be empowered to apply bugfixes as they see fit, and set roadmaps for future releases, while continuing the discussions on the more technical points. It is painful to see trivial bugfixes pending in pull requests with no one to pick them up.

What if there is no consensus? Well, the BPFK has a formal Chair. Why not having him have the final word on what goes in and goes out, when consensus cannot be reached?

To complete the proposal, the LLG should just acknowledge the current dire situation. The BPFK should stop being considered as a formal committee (for some reason they always remind me of this sketch) and just be taken for what it is: a group of volunteers that is given control of some core resources, in the hope that the group will develop them and make the Lojban ecosystem better over time. The BPFK should be free to set its preferred direction for the project, subject to the usual pressures of open source communities: the threat to lose users/contributors if they are too much alienated, or be subject to debilitating forks. A simple way to manage conflicts would be to give one member the power to have the final say on what goes in, as said before. This would also be subject to the usual counterbalancing pressures of open source communities. This role could be seen as a sort of "lead developer&= quot; within a group of "core developers", to continue the analogy = with software projects. Or a "release manager", as said in another= post.

Just my 2 cents...

--
You received this message because you are subscribed to the Google Groups &= quot;lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to lojban+unsub= scribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at http= s://groups.google.com/group/lojban.
For more options, visit http= s://groups.google.com/d/optout.
------=_Part_7048_601534940.1512983189104-- ------=_Part_7047_1417425202.1512983189103--