Also, I do not understand why the *language* committee has a role in this in the first place. Is closing projects often about whether or not it actually is a language (the expertise field of langcom)?
Most close requests are for projects that would not have been created under the current strictr langcom guidelines.
Sometimes I think Langcom might better be called a "New Project Editions" committee, since they review not only whether a new project would be lingiustically distinct or has its orthography sorted out, but also whether there is a sufficient body of editors to make a new language-edition successful. Both opening and closing arguments about specific language-editions of a Project hinge at times on language, and on the activity level of those advocating for keeping/creating it.
On Sat, Jun 25, 2011 at 5:20 AM, Lodewijk lodewijk@effeietsanders.org wrote:
could someone perhaps explain why the board delegated closing policy to *individual language committee members*? Because as I read it, this advice to the board is given by one individual, even if the rest of the committee disagrees
I don't understand this part myself. But every committee has a certain leeway to decide how they will reach decisions.
*Sj and Ting informed us that Board has agreed with the policy after the discussion.
<
If i understand right that was in Berlin. So the Board had 2 months to put that in a resolution, and didn't. That doesn't sound as a approval to me.
The proposed LangCom policy update was shared within the past few weeks.
The Board didn't hold a vote or pass a resolution; as with other langcom recommendations, we discussed the proposed changes and had the option to veto them but did not. I think this is a fine way for LangCom to present proposed closures of language-editions to the Board, where there is no community consensus. [For comparison: any group is welcome to present recommendations, or suggest resolution language, to the Board at any time; however this goes smoother when there is a process laid out ahead of time.]
I don't think this new langcom policy should override the existing option of using community consensus to close a project -- that simply happens very rarely.
SJ