Talk:Closing projects policy/Archives/2011

Closing projects policy

• I think this is a very good proposal. It is very important to make a policy on this, or at least some kind of guideline. --OosWesThoesBes 07:18, 8 March 2011 (UTC)

• It's a good start, and it's really needed; I especially like "inactivity is not a valid reason." I am, however, skeptical, about the notion of "voting". Seb az86556 17:42, 13 March 2011 (UTC)
  • I agree, but as of now the basis to pass a request are the votes. I try to emphasize that arguments are needed. In case of community voting, 2/3 is needed to pass the request. In case of LangCom decision, arguments are also more important than votes. But votes are inevitable, because when requesting a new language edition, people still vote even though voting is not allowed. SPQRobin (talk) 21:17, 13 March 2011 (UTC)
    • That's true. I realize you're trying to square the proverbial circle here. Seb az86556 22:25, 13 March 2011 (UTC)
• Thumbs up. Malafaya 18:04, 14 March 2011 (UTC)
• I'm just fearing that relying on votes too much may encourage all the canvassing votes that have in the past been made on pretty much every single request related to closing Wikipedias or Simple English projects. -- Prince Kassad 19:05, 16 March 2011 (UTC)
  • I agree. As I said above, I tried to reduce relying on votes. If you have a concrete idea to reduce it even more, that is welcome. (I think it's impossible to forbid voting, because people would still vote even if it's not allowed). SPQRobin (talk) 20:39, 16 March 2011 (UTC)
    • I especially don't like the fact that even if the community consents a majority is required. This allows a meta vote to override community consensus, which shouldn't happen ever. -- Prince Kassad 22:03, 17 March 2011 (UTC)
      • I understand, but it still is about closing or possibly even deleting a wiki, so I think for such an radical decision, confirmation by Meta voters is needed. SPQRobin (talk) 20:04, 3 April 2011 (UTC)
•  Support If this becomes an official policy, it would clearly explain the importance of how a proposal for closing projects is. This would keep normal users from being too happy about closing projects. Hydriz 14:58, 6 April 2011 (UTC)

"clean-up" as third-option-!vote

In general, any such proposal should include a third voting option in addition to "support" and "oppose": "clean-up". A call for "clean-up" would mean "I want the project to be kept, but I am in favor of a blank-cheque to radically delete any "article" that has less then two or three sentences." Seb az86556 19:39, 16 March 2011 (UTC)

I have not much seen this in proposals for closing projects, but if there is need for it, it can certainly be added as an option. SPQRobin (talk) 20:39, 16 March 2011 (UTC)

I do believe it is one of the main reasons why these proposals often end up resulting in no action whatsoever. If the only choice is a dichotomy between total doom and doing nothing, the oppose-votes will mostly prevail. It is similar to having a vote on a patient that comes complaining about migraines or toothache: "Everybody in favor of beheading, please vote support." — of course there will be those who say "yeah, but it's just a toothache." Seb az86556 00:36, 17 March 2011 (UTC)

Yes, but such stubs do not harm that much, and I think such a clean-up would be done by local users if a wiki is active enough. If it is inactive and the wiki includes only a few such stubs, it qualifies as "absence of content since the wiki's creation" which is a valid reason for closure/deletion. Also, how would you define a majority that is needed to approve a proposal (would you count "clean-up" as "oppose" or as a different option)? SPQRobin (talk) 20:36, 3 April 2011 (UTC)

If you do need a headcount, then yeah, clean-up is technically an opposition to closing. The problem I see with these polls in general is that everybody comes out of the woods (even people who have possibly never even heard of xx.wiki) to scream "oppose!" "unfairness!" "genocide!" — and then they disappear, go home, and absolutely nothing happens. Seb az86556 02:59, 4 April 2011 (UTC)

I totally agree with you, but I do not think that clean-up (deleting stubs) would help. I agree that nothing happening is not good, but what should be done? Currently, closing projects is seen as a way to "solve" the problem of inactive wikis, however this is a totally wrong way to address the problem. So my intention was to restrict wiki closure to real problems. Ideally, something like "Requests for clean-up" or "Requests for wiki review" should be set-up to deal with small, inactive wikis. But (realistically) no-one would be interested in dealing with that. SPQRobin (talk) 17:54, 4 April 2011 (UTC)

I would be :) If I was given the mandate to prune a given wikipedia, I would have no quarrels getting out the axe. Seb az86556 20:50, 4 April 2011 (UTC)

You're welcome to start such a page. Until now I've largely done this on my own, but I feel collaboration would be helpful there. -- Prince Kassad 21:00, 4 April 2011 (UTC)

I think if you request the needed rights (temporarily) on RFP, you can clean-up a wiki. As long as you have good intentions, you don't need a "mandate" I suppose. SPQRobin (talk) 22:12, 4 April 2011 (UTC)

The extend and method I have in mind would make it better to have such a mandate; otherwise, I could easily imagine that people will soon be screaming "omg, Seb goes around getting local sysop rights to vandalize small wikis!" Take the example of chy: — I'd prune redlink-lists and meaningless stuff which only has a picture and yet has nothing to do with Cheyenne. Seb az86556 05:26, 5 April 2011 (UTC)

I understand. But as I already said, I'm not convinced this would help. Anyway, if the majority agrees to do such a clean-up (either here for the policy, or on a case-by-case basis), that can be done. SPQRobin (talk) 15:54, 6 April 2011 (UTC)

Rights and closed wikis

Folks who are following this proposal may be interested in Requests for comment/Rights and closed wikis, which may be closed soon. ~ Ningauble 15:36, 15 April 2011 (UTC)

mailing list

Why are decisions supposed to be discussed on a mailing list and not publicly? Seb az86556 16:50, 19 May 2011 (UTC)

Because the language committee works via a mailing list, so we use this as well for discussing/deciding these proposals. SPQRobin (talk) 15:22, 20 May 2011 (UTC)

It robs the whole process of transparency. Seb az86556 15:38, 20 May 2011 (UTC)

The position of "observer" will be introduced around the same time, so anyone can ask to become an observer on the langcom mailing list. Also, mails are archived to Language committee/Archives (outdated, admittedly). SPQRobin (talk) 17:37, 20 May 2011 (UTC)

There will be one month of public discussion on Meta, then 15 days discussion on LangCom mailing list. --Millosh 22:40, 20 May 2011 (UTC)

Comments on the current draft

I completely agree that greater clarity is needed in this process, but I am not sure the current draft is ready for adoption.[1] Here is my perspective on a few of the particulars:

1. Types of proposals — If size and inactivity are not in themselves valid reasons for deletion, then what purpose is served by requiring that proposals be classified according to the size and activity level of the wiki? Is it to say that under "Proposal approved" large or active wikis are ineligible for transfer to the Incubator?
2. Type 2 proposals — It is not at all clear to me what it means as a criterion for deletion that a wiki be deemed "uncommon." (I consider en.wikipedia to be in a class by itself but...)
3. Definition of actions — I do not understand why the files of transferred wikis should be left in situ. If the wiki has gone somewhere else, shouldn't it be gone?
4. Proposing — Regarding the antepenultimate sub-bullet: "When the Wikimedia Incubator is at a stage where it is usable to a certain extent like a real wiki, inactivity will be a valid reason." Does this refer to projects being developed at the Incubator? I thought the scope of this policy related to "real" projects with their own (sub-)domain, such as are ordinarily discussed here at Meta. What is the rationale for inactivity being a valid reason at the Incubator but not at "independent" wikis?
5. Decision — This could use some greater clarity. What purpose is served by having the committee discuss the decision off-wiki for weeks? Apart from endorsing or overruling the consensus of public discussion, what types of actions are contemplated? Or, what purpose is served by the public discussion? Should it be re-characterized as "public comment" for the information of the committee?

Finally, since this policy proposes to delegate an authority to the committee that had previously been the vested in the community at large, ought it not be adopted by the community at large rather than by the communitycommittee itself? ~ Ningauble 17:53, 20 May 2011 (UTC)(corrected by Ningauble 17:52, 21 May 2011 (UTC))

Good points. I'm particularly interested in some clarification about this "mega-incubator" idea. Seb az86556

1. Types of proposals: you put the emphasis on the size/activity factor, while this is only an indicator of the distinction between regular language editions and special projects. And also, the purpose is to classify 'regular' proposals under type 1 and other proposals that are usually more complicated. I think it's logical that e.g. Quality Wikimedia and e.g. Afar Wiktionary should not be handled the same way? Type 2 may also be transferred to the Incubator, but this is unlikely since type 2 is indeed about 'special' cases.
2. Type 2 proposals: "uncommon" is just a catch-all term for any other wiki that is proposed for closure/deletion. There is no restriction on proposing a wiki for closure/deletion, so any wiki that does not fit in type 1 should go to type 2.
3. Definition of actions: it says explicitly "because of a lack of an export function". When there is a software feature that allows transferring files easily, this practice should be changed.
4. Proposing: Until now, the Incubator served as a "first step" before a language could get its own subdomain. The Incubator admins and language committee think that Incubator will become a project serving not only as a first step but also as a more definitive place for language editions that are not viable enough to have their own sub-domain (which is de facto already the case so far for some test wikis). For this, we are working on increasing Incubator's usability so that test wikis over there will be a sort of "virtual wikis". An advantage is that it is easier and better to have one wiki taking care of several smaller projects than having a lot of tiny wikis without maintenance.
5. Decision: We cannot foresee what will come out of this or how exactly we will handle closing projects. Especially since in the short term, there will be a lot of case-by-case decisions. In any case, I am sure that it is better for everyone to have language committee members decide on this subject. I did not completely understand what you wanted to have clarified, so please ask if you want more explanation.

As for your last question, do you mean "... rather than by the committee itself" instead of "...community itself"? Btw, I edited the page with some clarifications (hopefully). Regards, SPQRobin (talk) 22:27, 20 May 2011 (UTC)

Basically, LangCom members took this just because the current process is not working. If there is significant opposition to the idea that LangCom members take this responsibility, we are fine with not doing anything. So, if there is significant number of those who think that LangCom shouldn't interfere with closing projects, we could make a quick poll. It is likely that even some members of LangCom would vote against taking this responsibility. I am personally fine with both options, while I think that it is more wiser to pull this process from the dead end. --Millosh 23:07, 20 May 2011 (UTC)

What LangCom members agreed is:

• Specific LangCom members, not LangCom itself, are responsible for closing discussions. --Millosh 23:07, 20 May 2011 (UTC)
• One of those members is sending suggestion to the Board after public discussion and after discussion at LangCom's mailing list. --Millosh 23:07, 20 May 2011 (UTC)
• Board has the final authority. It is likely that Board would follow suggestions of particular LangCom member, but it is up to them to decide. --Millosh 23:07, 20 May 2011 (UTC)

There are some obvious issues. Let's say, our intention is not to close inactive project because we don't want to support small projects, but because it is more efficient to have them in Incubator. So, such projects would be moved to Incubator. --Millosh 23:07, 20 May 2011 (UTC)

There are some issues which are not obvious and which require qualitative decision. For example, closure of Simple English Wikiquote. If community wants it removed, it is not likely that it would get its space on Incubator. --Millosh 23:07, 20 May 2011 (UTC)

Anyway, besides (1) three points above (what LangCom members agreed), which are mandatory if we are taking this responsibility; (2) the fact that we would be fine with not taking it and (3) requirement that proposal should be in agreement with Language proposal policy (which would be slightly changed in relation to the acceptance of projects; it will become slightly broader) -- everything else is for discussion. If you have specific proposals, please, write them. We have 7 days for discussion about this policy, but if there are people who are interested in this issue, we can prolong it for, let's say, a month. --Millosh 23:07, 20 May 2011 (UTC)

Thanks for the clarifications. I think I have a better understanding of the intent now. Here are a couple suggestions:

• Types of proposals — I put the emphasis on the size/activity factor because that is what the sentence opened with. The subsequent change[2] is better. I think my misunderstanding was due to the section heading "Types of proposal." From discussion I gather that this is about describing the nature of the project, but I had been expecting it to be about the nature of what is proposed or why it is proposed.

  For greater clarity, I suggest re-naming the section as "Types of projects" and adding an introductory sentence to the effect that "In order to distinguish routine situations from potentially more complex or unusual ones, projects that are proposed to be deleted are classified as one of two types:"

• Decision — This seems to be the real bottom line of the entire proposed policy: that the decision is up to a committee member, subject to board ratification. If I am understanding the intent correctly, this is no longer going to be a situation of "closing a discussion" by assessing community consensus, but rather, it will be a case of taking community comment under advisement when exercising an autonomous prerogative. I suppose the language is clear enough, but it is such a major departure from prior custom that it might to good to make the lede section a little more explicit than "through Language Committee members." E.g. "by petitioning the Language Committee (members)." I just think it could be a little clearer at the outset that this is where authority is vested because I had almost reached the bottom of the page before I realized this.

One general observation: I agree that the current process lacks clarity and does not work well. It is unfortunate that the committee feels it would not work to handle this by acting as a body either. The proposed solution, to just have a trusted person volunteer to expedite proposals, is a clear recipe for decisiveness, but the basis for any affirmative decision to close (other than lack of content) remains as ad hoc and unclear as ever. ~ Ningauble 15:57, 22 May 2011 (UTC)

I share the concerns with regards to the final decision's being in the hand of only one person. This might very well work when it comes to creating a project ("Let's build a house") as is currently the case, but I am skeptical if that same process is a good idea when it comes to deleting projects ("Let's bomb that house"). Seb az86556 16:08, 22 May 2011 (UTC)

@Ningauble: Thanks, now I know that the text was not really clear. I have improved the text for easier understanding. As to your observation, there are several common reasons that are either defined as valid or invalid. This is mainly for type 1. For type 2, there will be a lot of case-by-case decisions obviously. And if you know other common reasons, please tell so we can add them to the policy. SPQRobin (talk) 19:57, 23 May 2011 (UTC)

@Seb: In fact, opening a project requires the approval of every LangCom member. For closing a project, we will not vote. The LangCom member in question will make his/her own decision based on community and other LangCom members' advice. Then this needs to pass Board approval. I think this is not "in the hand of only one person", because I know that the LangCom member in question won't make a decision contrary to everyone else's advice, that would be able to pass the Board. SPQRobin (talk) 19:57, 23 May 2011 (UTC)

language committee

The language committee will not vote on closures. The reason for this is that some, myself included, are dead against the closure of projects. This is why we will not vote because when we do, one vote against will torpedo a closure.

In the language committee we have competent people who have a mind of their own. When the LC is asked for an opinion, it will be for those members who are interested in coping with closing projects to consider the arguments provided. Consequently it is hardly interested who says what and why because they can do explicitly whatever they want or think is right. Thanks, GerardM 23:01, 20 May 2011 (UTC)

Incubator extension and redirects

Seb asked for clarification about Incubator improvements. Here is my quote from foundation-l list: --Millosh 23:18, 20 May 2011 (UTC)

We will soon have implemented Incubator extension on Incubator. The extensions is written by Robin Pepermans (a LangCom member and Incubator admin) and it will make Incubator more useful for those who create new projects.

In relation to this issue, Incubator projects will get their own virtual codes. For example, http://xyz.wikisource.org/ will be a redirect to http://incubator.wikimedia.org/wiki/Ws/Xyz.

If technically possible (I'll send the list of the codes to Mark and he will discuss with other admins is it possible to implement without problems), all ISO 639-3 codes will get such redirect to the Incubator page which would have the text similar to "Wikipedia in this language doesn't exist. If you speak this language, feel free to start it!"

This will be implemented in a couple of steps. I'll write the proposal at Meta, inform you here and after fixing issues if any, that will be implemented step by step.

The final product will be Incubator with all small projects, but with virtually all infrastructure needed to see that project as normal Wikimedia project.

The main goal of that is to allow many languages to have their own projects, although they don't have enough manpower to keep the whole project in function (many of their technical needs would be covered by Incubator admins).

I've got a number of the same questions in relation to this issue: If they have virtually everything, why would they create new articles to become independent project? I answered with the question: Why you create new articles on your own projects?

The point is that it is not likely to expect that a language with less than 100,000 speakers will every have sufficient number of people interested in Wikipedia projects to become a separate one. At the other side, of course, we still have many possible projects which could be separate at some point of time.

--Millosh 23:18, 20 May 2011 (UTC)

Thank you. That's not exactly what I meant, though. My question was not so much about projects which do not yet exist, but rather the passage (footnote) where it says "normal wikis that are not large enough to need an own wiki" will be moved to incubator. What exactly does "not large enough" mean here? Seb az86556 00:11, 21 May 2011 (UTC)

Wikis which are not self-sustainable (actually, it is better wording than "not large enough"). So, wikis which, let's say, don't have active admins; wikis which don't have edits for days (we have wikis which don't have non-bot edits for months). However, in all cases that has to pass community discussion as proposal for closing project. --Millosh 03:08, 21 May 2011 (UTC)

The point is: when we get improvements described above, it would be perfectly same from the visibility point for one small project would it be a separate project or incubator project. If there is no community or community wants help of Incubator admins, they could stay or back to Incubator. If community is self-sustainable, there would be no need for that. --Millosh 03:08, 21 May 2011 (UTC)

Maybe we should even split "Proposals for closing projects" from "Proposals for moving projects to Incubator" in the future. --Millosh 03:53, 21 May 2011 (UTC)

And here is one direct answer about the issue which bothers you: While you care about Navajo Wikipedia regularly and you think that it is not useful for you to have Incubator admin help, I see no reason to move it to Incubator :) --Millosh 03:58, 21 May 2011 (UTC)

(ec) (yeah, thanks...:P... that's nice... indeed one of my concerns! but I imagine there are others who are not as vocal as I am, so I have to pester you some more to understand the whole way of thinking here...)

I see, good explanation.

Now — what exactly is the rationale for this? (maybe I'm just too dense right now...) Is it cheaper ($) to have http://incubator.wikimedia.org/wiki/Ws/Xyz instead of http://xyz.wikisource.org/? Since there is now a global sysop-group to take care of vandalism across the field, I can't seem to understand why something should be moved around like that when the result is merely a different address... What would be the advantage? (before global-sysops, I would have understood "we need everything in one place to keep an eye on it"... but now?) Seb az86556 04:03, 21 May 2011 (UTC)

The initial idea was not about moving projects back to Incubator, but making life easier for those which are there and which likely won't go outside ever. --Millosh 04:39, 21 May 2011 (UTC)

• It could be about languages with very small number of speakers, but it could be also about, let's say, Navajo Wikibooks. The first question for you is: Do you have time to write one schoolbook in Navajo for two years? The second is: Do you have time to maintain both: Wikipedia and Wikibooks? As I may guess the answers, I would tell to you that you can keep working on separate Wikipedia, while virtually having all other Wikimedia projects, although you don't have time to keep all of them. --Millosh 04:39, 21 May 2011 (UTC)
  • Agreed: I have stated many times that spin-offs such as -books or -tionary are an utter waste of resources when the corresponding -pedia isn't over a certain size. And, personally, I have no interest in any of those types of endeavors. Seb az86556 05:53, 21 May 2011 (UTC)

• The second issue is related to approving projects. It is highly unlikely that a project with one active person -- like Navajo Wikipedia is now -- would be ever approved. (I suppose that Navajo got Wikipedia during the initial creation projects for all languages with ISO 639-1 codes.) I've spent a lot of explanations to push approval of some projects when I saw one or two dedicated persons. It is completely different to have http://incubator.wikimedia.org/wiki/Wp/Xyz namespace than http://xyz.wikipedia.org/. By having such redirect -- that readers see the project as regular Wikipedia -- all of their needs except project independence would be fulfilled. --Millosh 04:39, 21 May 2011 (UTC)
  • (Correction: we are 3. I am simply at the moment the one with the most time to waste it seems. All of the longer articles were written by nv:User:Arizona86002; he should get at least some credit here. Seb az86556 05:53, 21 May 2011 (UTC))

• The next issue is related to the fact which you've mentioned: You are highly involved Wikimedian and you don't have problems in relation to searching for help of any kind. Many editors of small projects are not so involved: they are not from US (I suppose that you are :) ) but from some developing country; many technical issues create serious problems to them; they feel alone, isolated from the rest of the community. All of those needs could be fulfilled by "mega Incubator" as you call it: at the time when we have, for example, ten Incubator-Wikipedias in South-East Asian languages with one active editor per project, they would be able to create a micro-community which is used for mutual help. I suppose that even you could benefit from something like that: micro-community of, let's say, US Native American Wikimedians inside of the Incubator could be beneficial for all members. --Millosh 04:39, 21 May 2011 (UTC)
  • I agree, if there are people who actually want help, that help should be given. I am, maybe due to my knowledge of history (worldwide), very skeptical of "forced help." Minorities have always been offered the "help" of larger powers, and when they said "thank you, but thank you no" — "help" was given at gunpoint. I guess I am very wary of this type of situation, for any project and any language; wherever the feedback is "Thank you for the offer, but at the moment, we are fine, and we do not require 'help'", that should be respected — unless it is objectively and measurably obvious that the project is being spammed, vandalized, or abused to the detriment of the WMF's reputation or possible legal liabilities. It is a psychological situation, in which (I believe) people will strive to do more when they are given more responsibility; on the other hand, the more help (however well-meaning) is provided, the more the old feeling of "we would not have been able to do this by ourselves" will prevail. Seb az86556 05:53, 21 May 2011 (UTC)
    • I mentioned above that I was pushing certain projects to be approved when I saw that they have one or two dedicated persons. Besides that fact, there is one more point about those projects: It is about minority languages from former Soviet Union and editors from a number of them, with couple of editors from Russian Wikipedia, created a kind of networked community for mutual help. Although those projects are separate, editors from different projects care about other projects. Such projects are de facto self-sustainable and even when Incubator changes become reality, there is no need to keep them at Incubator if they don't want that. --Millosh 06:38, 21 May 2011 (UTC)
    • The moral from that is that it is completely possible that minorities help each other and that there is no need to feel dependent on larger communities. While it is not possible that one small language community would be able to get texts in its native language from outsiders, it is fully possible to share various kinds of other knowledge: you may create bots, someone else may create templates, the third person may take care about factual accuracy of the basic data about, let's say, planets -- all over the projects; etc. So, instead of searching for help from majorities, if you don't feel safe, you can empower yourselves through cooperation. --Millosh 06:38, 21 May 2011 (UTC)
    • Besides that, the most of humans are at some point minority. I don't think that one WASP American feels like a member of majority in New York City or in California. I am a member of majority in my country, but whenever I interact on Internet outside of places in my native language, it is hard for me to fine any person from my country. In other words, globalization and Internet have changed things a lot. Wikimedia community is probably at the top of the places where majorization is unacceptable. So, while I think that you should care about your rights, I think that you can relax a bit now. The time of cultural imperialism is passing -- slowly but surely. --Millosh 06:38, 21 May 2011 (UTC)

• When we have such infrastructure, the logical step is to move one category of dead projects to Incubator. While many Wikibooks projects are not so active, they have passive community from corresponding Wikipedias. That's the field for global sysops work (besides the fact that Incubator is also inside of the gs set). They could benefit from going back to Incubator, but there is no reason to force them there, as they are de facto self-sustainable. However, many projects don't have anyone to keep the project. And project with at least good look of Main Page has better chances to get some editors, than a project with mess on it. --Millosh 04:39, 21 May 2011 (UTC)

Preemption and retroactivity

Please note that at least one board member has expressed the view that "I don't think this new langcom policy should override the existing option of using community consensus to close a project."[3] I think that, except when a proposal is clearly specious vandalism or trollery, the committee should be charged with bringing every proposal to the board with a recommendation one way or the other. This would prevent the committee from using a "pocket veto" to override community consensus. ~ Ningauble 15:00, 28 June 2011 (UTC)

There is no need to worry in relation to the projects closure. There are clear rules for inactive projects and projects without content. The other type of closure is about community consensus. By arguments, not by voting. And, of course, at the end, Board has the final word. If Language committee member(s) don't agree with the will of the community, that will be noticed along with recommendation. --Millosh 16:45, 28 June 2011 (UTC)

BTW, you've given to me one interesting idea. As it is about particular LangCom's members, I will send my recommendations publicly, at foundation-l. --Millosh 16:45, 28 June 2011 (UTC)

Ningauble -- that's a good principle. Any community consensus to close a project should be brought to the Board. The LangCom is an obvious intermediary to do this, since they handle most closure requests; but a community group that feels it has somehow been overridden is welcome to bring a request to the Board directly -- we are readily accessible by mail and via our individual talk pages. –SJ talk | translate   19:04, 21 July 2011 (UTC)

I agree. But the community should not be able to decide on the closure of a project on its own - as it used to be. It's fine when the Board is consulted directly, without LangCom recommendation, as long as we, the LangCom, (or that's how I feel, at least) are informed. SPQRobin (talk) 19:48, 21 July 2011 (UTC)

Sj, Ningauble: That's the deal anyway. Any controversial issue should be brought to the Board with presented arguments and pointing to the discussion. Actually, as I said, as one of the LangCom members who takes care about the requests, I would inform community about all of the recommendations. --Millosh 20:17, 22 July 2011 (UTC)

Robin, I don't think that the problem was in "community", but in random individuals who were closing requests according to their wishes by announcing "consensus", although there were no consensus. Basically, LangCom members are taking responsibility of closing discussion according to the principles of the new policy. I would trust to a wide range of Wikimedians to do that job, but a couple of previous closures were parodies because of that randomness. Ultimately, community should be able to close any project if there is near-consensus majority (~80% of valid contributors after discussion with many participants). I don't think that we should go against such community will (actually, if it is against the policy, Board should be informed about that, as well). All other issues are open to Board's ultimate decision. --Millosh 20:17, 22 July 2011 (UTC)

Yes, indeed, the biggest problem was with individuals closing requests according to their wishes. But still, I find it counter-intuitive if it is possible to close a project through community consensus but not open a project with community consensus. SPQRobin (talk) 22:09, 22 July 2011 (UTC)

Transparency, accountability, and precedents

Since the adoption of this policy, four proposals to close projects have now been processed. Reviewing how these have been handled, the process has not met my expectations. In particular:

1. In no case was the committee's report to the board, with recommended action and rationale, posted where it available for community viewing.
2. In no case was a board resolution or official action on the recommendation posted where it available for community viewing.
3. In only one case did the committee provide a rationale to the community.dif

It may be noted that, after most of these proposals were initiated, this policy was amended to vitiate the principle that this is to be a board decision.[4] This appears to be consistent with discussion in a previous thread that the board has not officially approved this policy, under which the decision was to be the responsibility of the board.

It might have been hoped that statements from parties responsible for recommending (Langcom) and enacting (Board) these decisions would contribute to the stated objective of bringing clarity and consistency to what had been a series of confusing ad hoc decisions. Without such statements this process contributes nothing to clarifying principles or precedents germane to these decisions.

What appears to be happening is, in short, the board is not ruling on these proposals, the committee may be discussing them privately before giving an unexplained thumbs-up or thumbs-down (with one exception noted above), and the outcomes are no different from what might have been expected from the previous practice. Notwithstanding the good intentions behind this policy, in practice the only thing that has changed, besides adding delays, is to reduce transparency. I think this exercise has been a failure, and I encourage both Langcom and the Board to take it more seriously. ~ Ningauble 16:55, 24 August 2011 (UTC)

Note that particular LangCom members are responsible for closing projects, not LangCom itself. In all cases decisions were on the line of community will (consensus is needed for changing current situation) and I don't think that it is a big deal why Robin didn't give particular rationale. Discussion on LangCom list about his proposals was non-existent. He suggested outcome, I explicitly agreed, nobody else commented, enough time passed, he sent proposal to the Board, nobody from the Board objected (that's the usual way of workflow between LangCom and Board), time passed and Robin concluded cases according to very straight principles. --Millosh 17:12, 24 August 2011 (UTC)

If you are concerned about LangCom actions, please apply for observer status. As you are a valid Wikimedia editor, there shouldn't be a problem for getting that status. Observers have been introduced exactly because of transparency. --Millosh 17:12, 24 August 2011 (UTC)

I appreciate the good-will offer, but I do not wish to subscribe to a mailing list. What I want is for those "very straight principles" to be stated publicly. ~ Ningauble 14:40, 25 August 2011 (UTC)

Agreed with Milos. I would like to add that I *did* note my proposed outcome: e.g. http://meta.wikimedia.org/w/index.php?diff=2756868&oldid=2756219 Your point that I should mention my rationale as well, is valid. I will in the future add the comment I give on the LangCom list as well. As for the Board, making resolutions or giving minutes is neither done for opening projects so I don't see why they would start doing this for closing projects. SPQRobin (talk) 20:27, 24 August 2011 (UTC)

I think what Ningauble is looking for is short hints, not some long essay, so that those who consider making the next proposal can take a good guess whether or not it's gonna sink or float. Seb az86556 22:56, 24 August 2011 (UTC)

Yep, and thanks to SPQRobin for undertaking to provide opinions. In cases with little or no debate it could be a single sentence. In cases that generate a lot of discussion it might be two or three sentences identifying the salient points. Nobody wants to read a 300 page Supreme Court decision, but it would be helpful to have something like, e.g., the "findings of principle" issued by ArbCom at en.wp.

Regarding board action, my experience may not be the broadest but I am not aware of any board that does not keep minutes of all of its official actions (including receipt of reports), and this is often mandated in bylaws or even in statute. That said, I am now understanding that these decisions are not really official board actions, but that board members are merely being given courtesy notices for oversight purposes. ~ Ningauble 14:40, 25 August 2011 (UTC)

You pushed me to find the exact email which describes how Board deals with committees :) During one of the discussions about LangCom-Board relations, Ting said that Board adopted so called "Responsibility assignment matrix", I think two years ago. The case is similar with ChapCom (Board isn't making decisions opposite of ChapCom's; while it has to make official resolution because of legal matters). Board doesn't interfere in stewards' actions, as well. --Millosh 15:48, 25 August 2011 (UTC)

Unlike this policy, the Stewards' policy does not say anything about sending recommendations to the Board or decision by the Board. Perhaps a careful review of the alignment between policy language and intended practice is in order. ~ Ningauble 16:19, 25 August 2011 (UTC)

Erm, it's clearly stated that the langcom member's recommendation "becomes" the board decision if the board doesn't react at all. So what is the problem? --MF-W 17:19, 25 August 2011 (UTC)

Well, inaction is not an act of the Board. It's not a "Board decision" on a "recommendation to the Board", it is simply advisement prior to exercising delegated authority. There is nothing wrong with doing things this way, but I don't think the quoted phrases, introduced in a recent revision of the policy, are the best way of describing it. If this reflects the committee's intent, I would suggest rewording the third bullet under Decision as follows:

• Thereafter, the initial LangCom member drafts a decision and notifies the community and the Board. The decision will be implemented one week after giving notice unless members of the Board, which has final authority, wish to take the matter up.

I also incorporated the notion of communicating to the community into this language. Sorry about being such a pest: I don't know if anyone on the Board even cares about the difference between exercises of delegated authority and actual actions of the Board. I do sincerely want the new process to be an improvement over the old ad hoc practice. ~ Ningauble 20:16, 25 August 2011 (UTC)

I don't see any problem with the current text but if nobody objects your text, I'd say feel free to change it. SPQRobin (talk) 21:09, 25 August 2011 (UTC)

Agreed with Robin. Ningauble, if you think that the wording should be better to represent the sense of the process, feel free to fix it. --Millosh 07:08, 26 August 2011 (UTC)

Done. To be clear, my intent here is to give better expression to the committee's intent, not to endorse what this policy has morphed into. ~ Ningauble 13:46, 27 August 2011 (UTC)

I agree that a good principle in closures is transparency of process, and clarity about what criteria are used in deciding to close. I do not feel the Board should be making this level of content-decision. I certainly do care about the difference between its own actions and delegated authority -- we are working actively to delegate more to community-run bodies such as this committee. The Board always has the capacity to get involved under dire circumstances; but when it comes to issues of content, it should almost never have to, nor should Board approval be a bottleneck. Even the Board approval of creating new language-editions is outdated: that too should be handled by the community body best positioned to do so - and with the last set of policy changes we are moving in that direction. For the rare circumstance of contested closures, I suggest that a community-run global requests committee, similarly delegated to by the Board, handle any appeals just as Ombudsmen today review difficult issues of user privacy. –SJ talk | translate   20:30, 28 August 2011 (UTC)

Speedy close

Having just seem some disruption over a speedy close of a project closing discussion for sco.wiki, and having some concept of how to maintain reasonable openness without wasting time in useless and unnecessary discussions, I'm editing the section that had been just revised to cover certain kinds of speedy closes. I've removed the language about "Vandalism, trolling, ignorant or bad faith proposals," because to claim that a proposal is made in bad faith, or is the other negative things, is an assumption of bad faith, which isn't necessary. There is an ordinary motion used by assemblies, "Objection to the consideration of the question," and it is summarily dealt with, immediately, because to debate it defeats the very purpose of the motion. Because there is no rush about closing a wiki, a proposal to close will not ordinarily be any kind of emergency.

Therefore I have proposed, first, that any member of LangComm may speedy close a discussion as unlikely to produce advice to close. It should really be a simple decision that the discussion is likely to be a waste of time, and "ignorant" or the rest does not need to be any part of it. Note that our policies here don't govern LangComm or the Board, but only what happens here on meta. We need this policy to understand how to handle proposals. If no member of LangComm can be found to support considering a proposed closure, there is little use in a closure discussion. Open closure discussions can damage wikis, causing uncertainty about the future, depressing contributions, often. Hence the appeal from a speedy closure is to any other member of LangComm, and any dispute over this between LangCom members, should that arise, should be resolved by the Committee itself.

Closure discussions can generate much heat, if there is an active wiki community!

I have also proposed that any WMF user in good standing may, for the welfare of the community, close a closure proposal as harmful, and that this should be reverted only by, again, a LangComm member. This could be made more complicated, but the reasoning behind allowing any user to close is that a proposal may attract a fair amount of comment and create concern on the affected wiki, with no need for that. What is being protected in this case is meta and the affected wikis. I assume that LangCom members will eventually see a speedy closed proposal and it would only take one to re-open it as worthy of discussion. --Abd 00:06, 27 August 2011 (UTC)

Agreed. In the case of sco.wp I reacted in protection of Meta, not because I had to close that discussion so soon, actually. It would be rejected anyway and from the LangCom point it is not important would it be closed the same day or a month or two later. --Millosh 08:50, 27 August 2011 (UTC)

But, may you reformulate the end of the sentence "...and it should not be re-opened save by a LangCom member." for us, non-native speakers of English? :) --Millosh 08:50, 27 August 2011 (UTC)

"Save by" means "except by." I'll change it. --Abd 18:08, 27 August 2011 (UTC)

Informing chapters

Per the recent discussion about Xitsonga and Sotho Wikipedia closures, with Wikimedia South Africa, I thought it would be a good idea to inform chapters when a wiki is proposed to be closed, that is in a language of which a relatively large group of speakers live in a country that has a recognised chapter (e.g. Sotho = WM ZA, Inuktitut = WM CA, ...). Any thoughts/comments? If no objections within some time, I will add it to the policy. SPQRobin (talk) 22:16, 6 September 2011 (UTC)

Such notice is a very good idea. Is there an index to chapters by language that can be used to identify affected chapters? Otherwise it might be impractical to expect nominators to track them down. ~ Ningauble 17:43, 7 September 2011 (UTC)

I created a list of chapters per Wikimedia language. All main chapters not between brackets would need to be informed. It took some time to make the list, but I think it is well worth it (in general, not just for the purpose of this). SPQRobin (talk) 02:00, 9 September 2011 (UTC)

Thanks. This will be a valuable resource in a variety of situations. ~ Ningauble 17:14, 9 September 2011 (UTC)

I added this to the policy. SPQRobin (talk) 11:02, 11 September 2011 (UTC)