Received: from mail-wr0-f191.google.com ([209.85.128.191]:46266) by stodi.digitalkingdom.org with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eHfIs-0006Rs-PN for lojban-list-archive@lojban.org; Wed, 22 Nov 2017 16:23:46 -0800 Received: by mail-wr0-f191.google.com with SMTP id t92sf11066821wrc.13 for ; Wed, 22 Nov 2017 16:23:42 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511396616; cv=pass; d=google.com; s=arc-20160816; b=iq4E75H30hVcYXPoXrYbbkZP+t8LIpbHDmM2ISs/MqO3y7J2Ro0eSy8Q7s0C1izqiq KoV8NSwVFlmzxUQwpK4dYWsM6OKJqgTCHz0mkkSE+lVX7KnL57Z4rtwYEZNRaIO6e4uh zuQpuYJjYotIkqem2uERlOCYPkjiajaHlbLQl5DsgPnwGT2TXFrSDn7w/pjojSYk0tzV A6DuYlgZP8qKfDDdcEW+QWJV1/9qEtu4B3F9ecfiloNdjspE2FBO1Ie7zmBnCbeltcIw 1xSzWk5tdRyEtocemXX8OndhKcR/h3zNBm5fzXIX9p9iKsP3EvdRb7Kc17eVMJcG6d3C 3pzQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:arc-authentication-results:arc-message-signature:sender :dkim-signature:arc-authentication-results; bh=OawFy//2AIs8pXc1RoaQjxK4aZTSrTwzfUWKMAtFDtE=; b=fBRRtOCUSbn4GKuZtM1VUkW0UXo9LpPvxWGO6MdsQ0mZqOSrSXQfvwUMf+kPP8Y11N +65BB4dkV3Xjm4v5SJsQgSIKdO5h7DhDPeY9iycgbMJfafaZotLtJF2SvioASynxTXP/ RZ5tfeJDaRx8FWInW6+FTH6siNKgFSNm184ENIlkYn4bgkgxfdgmBKOjjCtaA/2N6ocA FmhguX5ypT0j3fnRStcJJ+FCVCIGUmARJUXUwRwU6dJc1nXLxSvgPDCsEJ4/mjYPUQel 4oK+Gl0uNPD76QLRXpypMD0Io/A5jdZxLVieOOgLoa6U+cPf0eRkEmjY+W4PbWhGCr6M GxkQ== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@posteo.net header.s=2017 header.b=UVvAPFi9; spf=pass (google.com: domain of greg_g@posteo.net designates 185.67.36.141 as permitted sender) smtp.mailfrom=greg_g@posteo.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=OawFy//2AIs8pXc1RoaQjxK4aZTSrTwzfUWKMAtFDtE=; b=kI+10cBiqDKJa4+PwCJy3TdUs/W3v8Ja9b4vnLfvz4B5qyjkdVZycLCVuACJhlSttE 1Em1SCvCYSLvcY8ISnliB/s7YdPluUQ/qiL5EKfBON2YB4KkXK2U/5fBvyU1+E+rDNvY 8xXempXwjxJYR1Rn59LsLz1SPsR+gCXhckeg+eW/xLf4aZ4zGKG0PkUjuyp3DR0xp35i 8HXCyHj6w7+7/BEvDLIDHZYaHBYsQcowGUrxlXpliHtZusZtZkPl9lgwowSuAy6dx/7v xqFFu8w5+DMeVkZIhzQ9BUx3Y1uMMCqbxGNoEWjBfEhz6gcgI4i8rVdt3oFYyKFCF0us u4gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=OawFy//2AIs8pXc1RoaQjxK4aZTSrTwzfUWKMAtFDtE=; b=AURwrRcXKV78zyrQt50me3VVLI8rUgwoREC3e7S7+jhtKwPAM5BLQ4UpA65zfCTFUk pudxHQrHSauEsAMZ3lnp+lZP9jbdAFDwiz4MpaUEIL0zq8DQSci3UDqyhYXiFtw4ut/m bREcO7oGxZYGeGbeVCqQwWgodeg3M9+CxERYNxanMlGA0Bo3Hd4Sm0ZtKxQU1Utk7el9 NXOtWfbT00saNJLNB1KfbYmdaD9l4d6KIEgky6SBMpQY5w9BOzNLwL4W8RKPtu7cc22N heVil+s+JyslE6AnoGUWoGyIZzzlCLQFL5M0ee1JqQzdLhOSc0KISYLzUMGG3H+if01f 6etw== Sender: lojban@googlegroups.com X-Gm-Message-State: AJaThX70gp/yzZBtiDrdauBhpLzA7WYbatwIwu7NN/idnHyGcbP6+8AI ZOwMnJf8GApB6jmz+QEVkYQ= X-Google-Smtp-Source: AGs4zMZ7Q4rhRAxYzADC99m7fVpbpSPMQ4GWJgs529md5CPKGm3R1i/2mXy4CIRNFwDgZRzEZBm23A== X-Received: by 10.28.225.68 with SMTP id y65mr76018wmg.7.1511396616078; Wed, 22 Nov 2017 16:23:36 -0800 (PST) X-BeenThere: lojban@googlegroups.com Received: by 10.80.144.196 with SMTP id d4ls2624274eda.4.gmail; Wed, 22 Nov 2017 16:23:35 -0800 (PST) X-Received: by 10.80.164.203 with SMTP id x11mr7153065edb.7.1511396615480; Wed, 22 Nov 2017 16:23:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511396615; cv=none; d=google.com; s=arc-20160816; b=XKfvPWiU1wID61I6c9rRJRWTfKV9K4EvVOuvplrV2yGQpNMb6aOK0b/8xy+koP46Rq LXl64CwyfVjT5GByzv1vfzlDnTKVJ2FRR0mRiZ2YgMXM8GwpU7qt5yG55yGLL2KqCHtL greylIE/xZY7qR9xYdFwvKEAg7+JSX63GBLjjd9MuvQRq9ZVBe+RchACT1++1xfRrHYd 35i09JlG/roSotuZn5/AVAf1LnEBhPAAAYqr8loeDiLV1wlqs2LqspMMGPrR5CIR9nS1 QlJ8kmOUMLGnQtUtvz+UpuPctOzvDU5UYO+NjiYxT4ybOfQmPdhwNsMmLFOw+Fwkm84e THmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature :arc-authentication-results; bh=3ZNB6+nGgVFFzkuRQIotLHvXlTKWBbyXIzaj+KuAwvQ=; b=MjZWMBcqZDdHFKpXzUsqz/KTPWFfnQ6dxAovvau61sRp1vlw23BtLTcJAdk2GyzOxI enFXH67MvQPJgwDBbSXtnyJIdCWyZ16byzInNe5veK8ZPrG544HmmFzH4OoDoCquE7b8 rLYpA+UdwNoT50fpZRmDDb2aC+/ZeWorG4cJdkWjU3fziZ6rJdwKHRf0YmuNy/HOfzcf y6HsRctuBV3UnK/ifb3nTaxjySuoocRJATvwXOMZg7lCYtSitKWAtteKJ5XlfkN/dShy SO09riHeCVzMz+XShO7oj20FML+p8WMPjA7vXHYN/j1kyJXjnRw9bz4A45b28fvHlPaE RJ0Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@posteo.net header.s=2017 header.b=UVvAPFi9; spf=pass (google.com: domain of greg_g@posteo.net designates 185.67.36.141 as permitted sender) smtp.mailfrom=greg_g@posteo.net Received: from mout01.posteo.de (mout01.posteo.de. [185.67.36.141]) by gmr-mx.google.com with ESMTPS id a23si1201337edd.1.2017.11.22.16.23.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 16:23:35 -0800 (PST) Received-SPF: pass (google.com: domain of greg_g@posteo.net designates 185.67.36.141 as permitted sender) client-ip=185.67.36.141; Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id CCA6920C53 for ; Thu, 23 Nov 2017 01:23:34 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3yj0RV30mkz9rxG for ; Thu, 23 Nov 2017 01:23:34 +0100 (CET) Subject: Re: [lojban] Re: CLL and modern Lojban To: lojban@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> From: Gregorio Guidi Message-ID: Date: Thu, 23 Nov 2017 01:23:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9755E17ECEB735C9539E46F1" Content-Language: en-US X-Original-Sender: greg_g@posteo.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@posteo.net header.s=2017 header.b=UVvAPFi9; spf=pass (google.com: domain of greg_g@posteo.net designates 185.67.36.141 as permitted sender) smtp.mailfrom=greg_g@posteo.net 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: -4.2 (----) X-Spam_score: -4.2 X-Spam_score_int: -41 X-Spam_bar: ---- This is a multi-part message in MIME format. --------------9755E17ECEB735C9539E46F1 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable On 11/22/2017 09:58 AM, sukender1@gmail.com wrote: > Alright. Time for my v0.2 proposal about submissions. I integrated=20 > what Gleki and Gregorio=C2=A0said, from the "simplified v0.1" version. > 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=20 > rules ended to be way too complex, not taking all important aspects=20 > into consideration, and unmaintainable. So I changed my mind and I am=20 > 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"). > o Level is rounded by *default* (so that "A1+" is not A2 but A1). > o 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 anyone else, > asserting the target is _AT LEAST_ the given level. > o 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. > o 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 least "N votes", (s)he get > that level. > o Ex: Gleki has 2 "C1", 5 "B2", and 3 "B1". > + If we require "50% / 5 votes", then he would be B2. > + For "50% / 6 votes", he would be "B2" too (C1 count, as it > is greater, leading to the "70% / 7 votes" B2 score). > + For "90% / 5 votes", he would be B1. > o That doesn't mean one is really "B2" for instance. 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 community 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=20 > former "expert" term. In the following diagram: > > * "[B1]" means "the authenticated user must be granted the language > level B1 or more". > * "[logic 2]" means "the authenticated user must 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 added. > > > > > > @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=20 and experts within the Lojban community. I like the goal that you have=20 in mind. What I doubt, however, is whether the approach can fit with the=20 limited 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=20 the wiki and the associated material, the lojban github account, the=20 mailing lists) and how they decide to develop those resources. How many=20 community members are candidates to fill those key roles?... How many=20 people speak Lojban and are currently actively involved in the project?=20 I don't know... maybe 10? Is it possible to build a complex structure on=20 top of this set of core people that would need to fill all key parts of=20 the workflow? Given the size, perhaps it would be reasonable to just=20 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=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=20 disclaimer, I note that the following observations come from me as an=20 external observer of the dynamics of the Lojban community, so I=20 apologize in advance for not being completely informed on some of the=20 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=20 driver of the development of the language, essentially leaving future=20 developments in the hands of the BPFK members (while maintaining the=20 power of approval for "official standards"). From what I can see, the=20 LLG has resources for carrying out only the bare minimum of activities:=20 the legal duties to continue existing as a legal entity, managing the=20 finances and the printing and distributions of the physical copies of=20 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) * 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=20 core lojban resources. Then there is the Lojban Coder's Group. What/who is it in practice? I=20 can see from the github pages that for the cll repository this is mostly=20 Robin Powell. Other members of the organization do not seem very active,=20 at least in comparison. Indeed Robin almost single-handedly managed to=20 produce version 1.1 of the CLL with years of dedicated work, clearly a=20 huge accomplishment, and this was done in addition to maintaining most=20 of the infrastructure (and being the previous BPFK Chair). I have the=20 impression, though, that after 1.1 he expects that someone else will=20 step up to the 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=20 to explain the conflicts between BPFK and Coder's Group... (after all=20 Ilmen is also a member of the BPFK, right?). I do not really find=20 anything clearly to blame on all sides, from a superficial perspective=20 it seems natural that community members work on their parsers while an=20 official fully-specified grammar and an associated parser is still not=20 available (and this is due since ~15 years, I believe?). In a sense, the=20 problem will solve itself once the BPFK releases an official final=20 baseline grammar with an 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=20 bugfixes as they see fit, and set roadmaps for future releases, while=20 continuing the discussions on the more technical points. It is painful=20 to see trivial bugfixes pending in pull requests with no one to pick=20 them up. What if there is no consensus? Well, the BPFK has a formal Chair. Why=20 not having him have the final word on what goes in and goes out, when=20 consensus 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=20 committee (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=20 Lojban ecosystem better over time. The BPFK should be free to set its=20 preferred direction for the project, subject to the usual pressures of=20 open source communities: the threat to lose users/contributors if they=20 are too much alienated, or be subject to debilitating forks. A simple=20 way to manage conflicts would be to give one member the power to have=20 the final say on what goes in, as said before. This would also be=20 subject to the usual counterbalancing pressures of open source=20 communities. This role could be seen as a sort of "lead developer"=20 within a group of "core developers", to continue the analogy with=20 software projects. Or a "release manager", as 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. --------------9755E17ECEB735C9539E46F1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 11/22/2017 09:58 AM, sukender1@gmail.com wrote:
Alright. Time for my v0.2 proposal about submissions. I integrated what Gleki and=C2=A0Gregorio=C2=A0said, from the "simplified v= 0.1" version.
To avoid having "actual experts" situation or the "anyone is expert" situation, I'm proposing a balanced way. I thought 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+" 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 anyone 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 least "N votes", (s)he get that level.
    • Ex: Gleki has 2 "C1", 5 "B2", and 3 "B1".
      • If we require "50% / 5 votes", then he would be B2.
      • For "50% / 6 votes", he would be "B2" 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 instance. 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 community 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 following diagram:
  • "[B1]" means "the authenticated user must be granted the language level B1 or more".
  • "[logic 2]" means "the authenticated user must 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 added.



@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 resources 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" 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.
--------------9755E17ECEB735C9539E46F1--