Language committee/Handbook (committee)
This is internal documentation for the committee; see the documentation for requesting users.
| Language committee |
|---|
 |
| For requesting users |
| For members |
| Information |
| Closing projects (voluntarily) |
Perennial task: Check Talk:Language committee for unanswered questions.
Verify as eligible / reject ineligible requests
[edit]Verifying a project as eligible means checking whether the language is eligible according to the "requisites for eligibility", which are defined in the policy. If you wish to do this for a request:
- Determine whether the language is eligible or not.
- Send a mail to the committee mailing list about it.
- In clearly negative cases (e.g. artificial language about which you can't even find a Google result), you can as well mark the request as rejected right away (although this is not strictly covered by the policy) and inform the mailing list about it. Some frivolous requests should also rather be deleted than giving any attention by formally rejecting them.
- In clearly positive cases, a short note will usually suffice, saying that the language has a valid ISO 639-3 code and that there seem to be no issues. The voting policy also allows any committee member to mark clearly eligible requests as eligible, without consulting the whole committee first. Requirements are: the language has a valid ISO 639-3 code, there are no significant issues with regard to the language itself, the population of speakers is significant.
- If nobody disagrees with your opinion within one week, proceed. Otherwise, proceed according to the outcome of the consensus.
- Edit the {{new wiki request}} template on the request page and change the "status" parameter to "eligible" or "rejected". You may want to add a "comment". If there is nothing to say because if it's an obvious case, consider to simply add your signature as it will make it easier to track when/why the request was declared as eligible. - Some request pages might still use the old {{ls-header}} template, which you could change to the new template (langcom/handbook has the documentation). If you are lazy, just change the parameter there, to e.g. {{ls-header|eligible|status=wp/en}}.
- Edit Requests for new languages: if a project was marked as eligible, simply change the line; if a project was rejected, move it to the "Closed requests" section as well.
You're done!
Final approval
[edit]- Propose approval of a project on the Langcom mailing list when you think it fulfills the criteria for final approval. It's useful to provide a link to the request page on Meta, and/or catanalysis and/or codelookup, and a brief explanation of why it is ready for a approval.
- If the project in question will be the first project in its language, add a note in your mail that a linguist needs to be contacted for the verification of the content. Or: Mail an expert you know / deem competent and inform the committee that you asked one for his opinion.
- If applicable, wait for someone to come up with an expert.
- If applicable, wait for a positive review from the expert. Expert reviews should be shared on the private list.
- If the review is negative, inform the community of the test-project about the objections, so that they can be fixed. Afterward, you can bring up approval anew (the other [activity] criteria still need to be fulfilled by then, of course).
- If there is full consensus for approval on the committee mailing list after at least 7 days (& a positive verification of the content, if needed), add a notice on Talk:Language committee that the project is being considered for approval, unless some strong arguments which were overlooked so far will be brought up during a week. – If there is no consensus, the project is not approved. You might propose it later again when objections are fixed.
- Proceed after the "Notification about proposed approval" has been on Talk:Langcom for at least 7 days:
- Update the request page (change "status" in the template to "approved" and add a comment).
- Check if configuration details (in the same template) are ready. If yes, file the Phabricator request (formerly known as a bug) using the link that now appears at the bottom of the expanded template. If not, ask the community to add them, then file the bug.
- Update RNL: move the request to the Closed section
- Make a note at the announcement section of Talk:Langcom, use {{tracked}} to link the Phabricator request and {{Section resolved|1=~~~~}} to mark the section for archival.
- Note it on incubator:I:SCL, the Incubator info page and incubator:I:Featured wikis
You're done!
Proposals for closing projects
[edit]- Take a request from proposals for closing projects that you think has been open for long enough (policy requirement: "at least several weeks"). Bring it up on the Langcom mailing list, including at least a tentative decision whether the proposal should be accepted (and the wiki be closed) or rejected (and the wiki stay open). Proposal and discussion time in Langcom should be at least one week.
- If the proposal gets rejected (project stays open):
- Note it on the request on Meta
- Update PCP
- If not rejected (project should be closed):
- After a week, mail the Board Liaison so the Board can step in if it wants to
- Proceed after 1 week:
- Update proposal on Meta
- Update PCP
- Do the proposed steps regarding the content (e.g. importing to Incubator or a different place; deletion; …) or have them done (e.g. by stewards / global sysops)
- Edit sitenotice on the wiki or have it edited
- File a bug on Phabricator requesting the closure