[Foundation-l] Criteria for the closure of projects.

[Florence Devouard]

Andrew Whitworth wrote:
> On Thu, Apr 10, 2008 at 8:23 AM, Gerard Meijssen
> <gerard.meijssen at gmail.com> wrote:
>>    - A project is not what it is advertised to be. For instance when a
>>    language is always written in a particular script, a project in any other
>>    script is problematic.
> 
> I agree with this condition. If en.wikipedia were written in a
> non-latin alphabet, that would be pretty unacceptable to most readers
> of it. This would also go for conlangs which do not have representable
> character sets (klingon comes to mind, although that project is
> already closed).
> 
> I worry that this requirement, without further qualification, would
> restrict projects like an ASL project which uses glyphs instead of
> actual handsigns.
> 
>>    - A project does not have at least 90% of the most relevant messages
>>    localised. For your information there are only 498 messages in this category
>>    at the moment.
> 
> I would probably prefer a gradient scale, especially for languages
> which have only one project. 75% might be a good barrier to entry for
> the first project in a language, 90-100% for additional projects. This
> could be similar to the requirements set for the creation of new
> projects, but extended to include projects created before the language
> subcommittee made those rules.
> 
>>    - A project should have at least 1000 articles. When there is nothing
>>    to see what is the point ?
> 
> It can take a long time for a new project to reach this goal. If we
> assume that a self-sustaining wiki project can grow exponentially (at
> least at first), the first couple hundred or thousand articles can
> take a long time. After this point, however, more articles will
> attract more editors, which in turn will produce more articles, ad
> infinitum.
> 
> I would prefer to see a condition which is based on annual growth.
> Active editing membership and number of articles should increase every
> year by a certain percentage until the project reaches a certain
> stable size. For very large projects, such as en.wikipedia, it's
> unreasonable to expect continued growth at a constant rate, so we need
> to include cut-offs where we don't expect a project to be growing at a
> constant rate anymore. Requiring growth in active membership can help
> to reduce bot-generated projects like Volapuk which has article growth
> but no new members.
> 
> 10% article growth per year (which is 100 articles if your project has
> 1000) is not an unreasonable requirement. 5% growth in active editors
> (1 new editor for a project that already has 20) would not be an
> unreasonable lower-limit either. Projects which can't meet even these
> modest requirements probably don't have a critical mass to continue
> growth and development.
> 
> Doing something like this would enable us to automate the entire
> process. At the end of the year we calculate the growth rates of all
> the projects, and send warning notices to projects which have not met
> their required growth rates. two years of poor performance causes the
> project to get closed and moved back to the incubator. Plus, we don't
> set hard limits, which can be problematic for newly-created projects.
> 
> --Andrew Whitworth

Andrew's suggestions seem fair to me. I would also point out (again) the 
importance of tagging the main page with the "If you are a speaker of 
that language and you are willing to contribute there, you should ask 
for unlocking there."
I am not convinced the system can be entirely automated, as growth in 
active editor could be circonvented by sockpuppetry.

Ant