Re: [Foundation-l] Commons and The Year of the Picture
On Mon, Jan 19, 2009 at 8:05 AM, Michael Snow wikipe...@verizon.net wrote: I deal with this regularly in a professional capacity, this is what stock photography firms are built on, and I can assure you that there is no adequate freely licensed stock photography resource in the world. Commons is the best there is, and it is barely usable, and then only sporadically. Maybe some people imagine we have too many pictures of people's cats and dogs, since those are popular subjects, but I'll say we don't have nearly enough even of that - and in particular we don't have enough variety. Suppose I wanted a picture of a dog and a cat together, a fairly mundane subject, for which I did at least find a category with 27 files at http://commons.wikimedia.org/wiki/Category:Cats_and_dogs. I suppose that's a start, but at a glance there's no way that provides enough options for what I might want, especially if I was particular about how they're posed or what breed they are. I think this comes back to something I already talked about when Commons only just started - we don't need the umptieth picture of a dog, but we do want more pictures of specific dog breeds (although as things are now, we're pretty much over-stuffed with the more popular dog breeds too), of dogs doing specific things, of dogs in specific situations etcetera. However, this takes more than just getting more pictures. It's also important that they are described well (George W. Bush talking is just another Bush picture, but if you know where he is speaking at what occasion it becomes much more), and that they are findable. -- André Engels, andreeng...@gmail.com ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Commons and The Year of the Picture
Hoi, How wonderful, the WIkimedia Foundation adopts the Swedish idea to dedicate 2009 as the year of the picture. There is a lot that we can achieve when we put our mind to it. So let me tell you about some of our needs and of our low hanging fruits. ==Diversity== Some people say that we only need one picture of a dog. One opposing view is that we have over 250 Wikipedias who all write about the dog, dog breeds etc. It would be boring if they all have to use the same illustration. When we started with Commons, the same picture was loaded on many projects and concentrating them in one location and annotating them once was one of the primary reasons for Commons. By having a rich collection of quality pictures we give children something to choose from when they illustrate their projects. ==Historical subjects and archives== For many historical subjects it is difficult to find appropriate illustrations. In 2008 the successful building of relations let to the opening up of the Bundesarchiv.. We got 100.000 images in a usable format. This is becoming a win-win situation because many of the annotations have been checked and feedback is provided to the Bundesarchiv. In the meantime, slowly but surely these images are working their way into our articles. This success story provides an argument that may convince other archives to open up their collection. ==Historical subjects and bias== We owe a debt of gratitude to archives like the Library of Congress. They prove great custodians of our cultural heritage. They are a primary source for illustrations for our historical subjects. The LoC even provides high resolution scans for download. This embarrassment of riches has one downside, their material is American and when we overly rely on American resources ourcollection of illustrations becomes inherently biased. The conclusion is obvious, we need more archives to cooperate with. The library of Alexandria is an obvious one, but we need to illustrate the historical persons, places and events from countries like Sudan, Bangladesh, South Africa as much and as well as the persons, places and events of the USA. ==Historical pictures and quality== Our aim is to provide high quality illustrations with our articles. When there is nothing available, almost any picture improves the quality of a picture. When better illustrations are found, the old pictures should be replaced. This does not mean that the original historical picture lost its value, it may mean that we only need a higher quality version of the same image. By keeping these pictures and by looking for a better scan or a restored version of the image we build on our portfolio of illustrative material. ==Restorations of illustrative material== A small group of our people spend much of their time restoring illustrative material, both images and sound. The quality of their work is recognised in the high number of featured pictures and sounds. There is a Wikibook on Image restoration. There is an open invitation to support anyone interested in this most important work. When 2009 is to be the year of the picture, I can only hope for a workshop on this subject in Argentina. I can also hope that the unfulfilled needs of this community get positive attention. ==Commons and language== Commons is only usable for people who speak English. A seven or eight year old is not likely to find a picture of a hynder. When our material is to be educational, we must be able to reach those people who are being educated. It has been proved that we can provide Commons with categories in multiple languages, with a category tree in multiple languages and with a search engine that allows a seven year to find this hynder. Half of the WMF traffic is in English. It is only half our public that we would do it for. ==Commons, tools and language II== Many software tools have sprung up around Commons. Commonist is one of the more prominent tools. After some discussion Commonist was included in Betawiki and it became practical to provide localisations to Commonist. In a couple of day more then twenty localisations were completed. We need more pictures from countries like the Philipines, Turkey, Slovenia and Macedonia and enabling people to contribute in their own language is a powerful tool. Commonist demonstrates that this can be do this if we put our mind and effort to this. ==Commons and usability== The other day I tried and failed to upload a crop from an historical picture. I asked someone well versed in the intricacies of the upload process to upload it for me. For me the upload process is broken. I am motivated about Commons but I fail at getting a picture in. Given that the Stanton project is about Wikipedia, we need a similar project for Commons. ==Commons== Commons is a great and important project. When we give more attention to it will prove to grow from an ugly duckling into a swan. Currently there are 3,8 million media files, what number are we aiming for at the end of the year
Re: [Foundation-l] Commons and The Year of the Picture
Hello, On Mon, Jan 19, 2009 at 8:05 AM, Michael Snow wikipe...@verizon.net wrote: The Swedish chapter had the idea to declare 2009 The Year of the Picture, to put a concerted effort into adding images to the Wikimedia Commons, along with using more illustrations in Wikipedia and elsewhere. I think this is absolutely a great idea. Making better use of visual material in our projects also fits in with the ongoing effort to improve quality. Let me say for the record that I wholeheartedly support this idea. On Mon, Jan 19, 2009 at 11:04 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Commons is only usable for people who speak English. A seven or eight year old is not likely to find a picture of a hynder. Indeed; although the Commons community has put a lot of energy in welcoming users from all origins, I know many regular Wikipedians who can't use Commons because they can't read English and they can't browse its content. Another issue is that Commons is not censored, and a seven-year-old child might as well fall upon the female genitals category. Imho the search engine of Commons should: * allow multilingual tags or categories (Gerard already suggested that, and Commons users have been waiting for such a feature for a very long time) * include a Safe mode for children. * allow some sort of rating to facilitate the search; as someone said elsewhere, Commons is a depository, and depositories are expected to host lots of junk. A rating feature would allow the best of Commons to be presented first during the search, and junk to be presented last. If we really want to make 2009 « the year of the picture », this initiative must imho be accompanied by a real development effort. There is currently one chapter employing a MediaWiki developer, and I know there are at least two other chapters considering sponsoring one. Perhaps a chapter-sponsored initiative could be devoted to some sort of search layer (in core or as an extension) that would implement these features. Perhaps this has already been considered as part of the Stanton usability initiative. -- Guillaume Paumier [[m:User:guillom]] ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Why is the software out of reach of the community?
Hello Brian, thanks for all your insights, bashing and vocal support of your pet ideas. I understand, that SMW is academically interesting concept (though there're contradicting ideas in academia too, suggesting natural language processing as an alternative, and this seems where currently research tries to go too), and it provides usability in niche cases (academic data crunching). I fail to see why you associate SMW with general usability we're trying to think about? Is that something we simple mortals cannot understand, or are you simply out of touch from reality? See, our project is special. a) We have mass collaboration at large b) We end up having mass collaboration on individual articles and topics c) We have mega-mass readership d) We have massive scope and depth And, oh well, we have to run software development to facilitate all that. As you may notice, the above list puts quite some huge constraints on what we can do. All our features end up being incremental, and even though in theory they are easy to revert, it is the mass collaboration that picks it up and moves to a stage where it is not that easy (and that happens everywhere, where lots of work is being done). So, you are attacking templates, which have helped to deal with nearly everything we do (and are tiny, compared to overall content they facilitate), and were part of incremental development of the site and where editing community was going. Of course, there are ways to make some of our template management way better (template catalogues, more visual editing of parameters, less special characters for casual editors), but they generally are how we imagine and do information management. Now, if you want to come up with academic attitudes, and start telling how ontology is important, and all the semantic meanings have to be highlighted, sure, go on, talk to community, they can do it without software support too - by normalizing templates, using templates for tagging relations, then use various external tools to build information overlays on top of that. Make us believe stuff like that has to be deployed by showing initiative in the communities, not by showing initiative by external parties. Once it comes to actual software engineering, we have quite limited resources, and quite important mandate and cause. We have to make sure, that readers will be able to read, editors will be able to edit, and foundation will still be able to support the project. We may not always try to be exceptionally perfect (Tim does ;-), but that is because we do not want to be too stressed either. So, when it comes to reader community, software is doing work for them. Some of readers end up engineering software to make it better. When it comes to editing community, software does the work for them. Some of editors end up engineering software to make it better. Which community are you talking about? BR, -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]] ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Language codes to rename
And the renaming of zh-yue: to yue: (or at least the promised redirect) is long overdue (see [[bugzilla:8217]]). H. ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Language codes to rename
And it would greatly facilitate interwiki traffics to have a code for a multilingual site (e.g. for the betawikiversity: and the multilingual wikisource, and the proposed multilingual wikibooks). See https://bugzilla.wikimedia.org/show_bug.cgi?id=13334 H. ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Why is the software out of reach of the community?
This community, which takes quite a bit of effort to communicate with, effort which I have not seen from the development team: Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by everybody in Wikipedia, in full consultation with the community consensus. -- Jimbo Waleshttp://en.wikipedia.org/wiki/User:Jimbo_Wales I've been told by a volunteer developer in that this quote is irrelevant. I wonder how many people believe that is true. On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas midom.li...@gmail.comwrote: Hello Brian, thanks for all your insights, bashing and vocal support of your pet ideas. I understand, that SMW is academically interesting concept (though there're contradicting ideas in academia too, suggesting natural language processing as an alternative, and this seems where currently research tries to go too), and it provides usability in niche cases (academic data crunching). I fail to see why you associate SMW with general usability we're trying to think about? Is that something we simple mortals cannot understand, or are you simply out of touch from reality? See, our project is special. a) We have mass collaboration at large b) We end up having mass collaboration on individual articles and topics c) We have mega-mass readership d) We have massive scope and depth And, oh well, we have to run software development to facilitate all that. As you may notice, the above list puts quite some huge constraints on what we can do. All our features end up being incremental, and even though in theory they are easy to revert, it is the mass collaboration that picks it up and moves to a stage where it is not that easy (and that happens everywhere, where lots of work is being done). So, you are attacking templates, which have helped to deal with nearly everything we do (and are tiny, compared to overall content they facilitate), and were part of incremental development of the site and where editing community was going. Of course, there are ways to make some of our template management way better (template catalogues, more visual editing of parameters, less special characters for casual editors), but they generally are how we imagine and do information management. Now, if you want to come up with academic attitudes, and start telling how ontology is important, and all the semantic meanings have to be highlighted, sure, go on, talk to community, they can do it without software support too - by normalizing templates, using templates for tagging relations, then use various external tools to build information overlays on top of that. Make us believe stuff like that has to be deployed by showing initiative in the communities, not by showing initiative by external parties. Once it comes to actual software engineering, we have quite limited resources, and quite important mandate and cause. We have to make sure, that readers will be able to read, editors will be able to edit, and foundation will still be able to support the project. We may not always try to be exceptionally perfect (Tim does ;-), but that is because we do not want to be too stressed either. So, when it comes to reader community, software is doing work for them. Some of readers end up engineering software to make it better. When it comes to editing community, software does the work for them. Some of editors end up engineering software to make it better. Which community are you talking about? BR, -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]] ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Why is the software out of reach of the community?
Gerard, I'm not sure I understood the full context of your e-mail. There is only one thing stopping it from going live in my opinion - developer enthusiasm. I don't think thats how things are supposed to work. On Mon, Jan 19, 2009 at 11:04 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I think it is correct. There is also nothing in there stopping Semantic MediaWiki from going live. Thanks, GerardM 2009/1/19 Brian brian.min...@colorado.edu This community, which takes quite a bit of effort to communicate with, effort which I have not seen from the development team: Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by everybody in Wikipedia, in full consultation with the community consensus. -- Jimbo Wales http://en.wikipedia.org/wiki/User:Jimbo_Wales I've been told by a volunteer developer in that this quote is irrelevant. I wonder how many people believe that is true. On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas midom.li...@gmail.com wrote: Hello Brian, thanks for all your insights, bashing and vocal support of your pet ideas. I understand, that SMW is academically interesting concept (though there're contradicting ideas in academia too, suggesting natural language processing as an alternative, and this seems where currently research tries to go too), and it provides usability in niche cases (academic data crunching). I fail to see why you associate SMW with general usability we're trying to think about? Is that something we simple mortals cannot understand, or are you simply out of touch from reality? See, our project is special. a) We have mass collaboration at large b) We end up having mass collaboration on individual articles and topics c) We have mega-mass readership d) We have massive scope and depth And, oh well, we have to run software development to facilitate all that. As you may notice, the above list puts quite some huge constraints on what we can do. All our features end up being incremental, and even though in theory they are easy to revert, it is the mass collaboration that picks it up and moves to a stage where it is not that easy (and that happens everywhere, where lots of work is being done). So, you are attacking templates, which have helped to deal with nearly everything we do (and are tiny, compared to overall content they facilitate), and were part of incremental development of the site and where editing community was going. Of course, there are ways to make some of our template management way better (template catalogues, more visual editing of parameters, less special characters for casual editors), but they generally are how we imagine and do information management. Now, if you want to come up with academic attitudes, and start telling how ontology is important, and all the semantic meanings have to be highlighted, sure, go on, talk to community, they can do it without software support too - by normalizing templates, using templates for tagging relations, then use various external tools to build information overlays on top of that. Make us believe stuff like that has to be deployed by showing initiative in the communities, not by showing initiative by external parties. Once it comes to actual software engineering, we have quite limited resources, and quite important mandate and cause. We have to make sure, that readers will be able to read, editors will be able to edit, and foundation will still be able to support the project. We may not always try to be exceptionally perfect (Tim does ;-), but that is because we do not want to be too stressed either. So, when it comes to reader community, software is doing work for them. Some of readers end up engineering software to make it better. When it comes to editing community, software does the work for them. Some of editors end up engineering software to make it better. Which community are you talking about? BR, -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]] ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
Re: [Foundation-l] Why is the software out of reach of the community?
Brian hett schreven: There is only one thing stopping it from going live in my opinion - developer enthusiasm. What about community consensus? Marcus Buck ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Why is the software out of reach of the community?
There cannot be community consensus if the developers are unwilling to seriously consider alternate technological solutions to the ones they come up with. That is a key piece of the broken process -- developers of SMW have presented their ideas to the community, but whether or not there was ever consensus (or could have been consensus) has not mattered since the developers were unwilling to give the software serious look. In other words, there has been a chilling effect. Why bother going to as many people as you can for input if that input will make no difference? On Mon, Jan 19, 2009 at 1:45 PM, Marcus Buck m...@marcusbuck.org wrote: Brian hett schreven: There is only one thing stopping it from going live in my opinion - developer enthusiasm. What about community consensus? Marcus Buck ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Language codes to rename
Beta wikiversity is a hub for multiligual cooperation and the incubator is just part of it. The proposed multilingual wikibooks is for hosting books which cannot find home comfortably in any language edition. It is fitting to have, for example, the link from a page in cs:Wikiversity to Beta:Wikiversity sitting on the left column together with other inter-lingual links - compare: http://cs.wikiversity.org/wiki/Mezin%C3%A1rodn%C3%AD_rok_astronomie and http://beta.wikiversity.org/wiki/International_Year_of_Astronomy H. 2009/1/19 Gerard Meijssen gerard.meijs...@gmail.com: Hoi, Both the multilingual Wikibooks and Wikiversity exist as a kind of Incubator. Given that the aim is to create the single language editions, it means a lot of double work. Not such a good idea imho. Thanks, GerardM 2009/1/19 H hillgentle...@gmail.com And it would greatly facilitate interwiki traffics to have a code for a multilingual site (e.g. for the betawikiversity: and the multilingual wikisource, and the proposed multilingual wikibooks). See https://bugzilla.wikimedia.org/show_bug.cgi?id=13334 H. ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Language codes to rename
H wrote: Beta wikiversity is a hub for multiligual cooperation and the incubator is just part of it. The proposed multilingual wikibooks is for hosting books which cannot find home comfortably in any language edition. It is fitting to have, for example, the link from a page in cs:Wikiversity to Beta:Wikiversity sitting on the left column together with other inter-lingual links - compare: http://cs.wikiversity.org/wiki/Mezin%C3%A1rodn%C3%AD_rok_astronomie and http://beta.wikiversity.org/wiki/International_Year_of_Astronomy H. Oldwikisource has a similar function. There is no double work since it frees Incubator to work with those projects that don't have such a broader interproject site. Ec 2009/1/19 Gerard Meijssen: Hoi, Both the multilingual Wikibooks and Wikiversity exist as a kind of Incubator. Given that the aim is to create the single language editions, it means a lot of double work. ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Board resolutions (chapters)
Michael Snow wrote: I've been assembling my notes from last week's board meeting to pass along. The first set of items I have to report is business from the chapters committee. All of these resolutions have been posted on the foundation website. We approved two new chapters, and there's something special about each of the two. Wikimedia New York City is special because it's the first one recognized under the new sub-national chapter guidelines. And Wikimedia UK is special because it's the second version of that chapter. For the sake of formality - and nobody does formality better than the British, which has been part of the difficulty - we revoked the recognition of the first one, which is dissolved or in the process of dissolving. Anyway, welcome to both of the new chapters! Also, two resolutions relating to the chapters committee's membership and procedures were approved. One recognizes the current members and the other allows the committee to determine its own membership in the future. This allows them to keep their work going without waiting for the board to pass a resolution (the board reserves the ability to appoint and remove members and will still be informed of changes). --Michael Snow Hello, For the sake of clarity, I'd like to ask that a mean is given to recognize that a sub-chapter is a sub-chapter rather than a chapter. If not in the name that we use within ourselves, at least on meta and internal pages. For now, I guess everyone from the house can guess that it is a subchapter, but when we have 50 chapters and 50 sub-chapters, it may not be so easy to deal with. For example, on meta, Wikimedia NYC is listed as chapters, not subchapters. http://meta.wikimedia.org/wiki/Wikimedia_New_York_City. And the name does not clarify the difference either (it could have been mandatory that names used be of the type Wikimedia + Country + blabla). Beyond this, could it be possible that the difference between a chapter and a sub chapter be published ? I know some guidelines circulated internally, but I do believe it should not only be internal. I went to the resolution authorizing its recognition as a sub-chapter (http://wikimediafoundation.org/wiki/Resolution:Approval_of_Wikimedia_New_York_City) and I found reference to Wikimedia Foundation: A Framework for Encouraging the Development of Sub-National Chapters, but no idea where to find this document. I thought I could click on the only link provided on the resolution (local chapters), but this one leads to http://wikimediafoundation.org/wiki/Local_chapters, which does not mention sub chapters, nor Wikimedia NYC, nor any framework for blablasubchapters. So, in effect, the resolution does not tell me anything beyond the fact that there seems to be sub-chapters and chapters. If there is a difference, what is it ? Both for external world and for us folks, it is important to understand the relationships existing organisations. Right now, the information is not provided. Could someone from the Foundation fix that and add the necessary information, eg * the text of the framework on wmf site * the link from the resolution to the framework page * an update of the chapter list on wmf site, to add the subchapters category OR the creation of a second list * on meta, subchapters must be categorized as subchapters, not chapters Ant ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
[Foundation-l] Board resolution on committees
Another item from the board meeting was reviewing the structure of Wikimedia committees. We've passed a resolution that defines these a little more, as well as dissolving a number that were created in the past but no longer function. The full text is at http://wikimediafoundation.org/wiki/Resolution:Wikimedia_Committees The chapters committee I pretty much covered yesterday. The language committee, which as I understand developed as a subgroup of the now-disbanded special projects committee, should function on its own. We'll take a closer look at some of the issues that have been raised in that area as well, but that goes beyond what we had time for, and it's more appropriate for us to consult with the committee first. The ombudsman committee, which has also been debated somewhat, we intend to continue for this year as an interim measure. It will be expanded to five members (currently we've identified four I believe, we should pass a resolution soon after one more has been chosen). For the time being, the role of the ombudsman committee remains limited to complaints about CheckUser that may involve the privacy policy. To be specific, it is only a foundation-level matter and a potential ombudsman issue if a complaint relates to disclosure of information, as that's the only way to violate the privacy policy. Someone with access merely using the CheckUser tool is not an ombudsman issue, such issues are up to the stewards and/or arbitration committees that regulate who has access. Finally, as suggested in the resolution, I'll mention that we need to reconstitute a committee to organize the board elections that will happen later this year. Jan-Bart has again accepted the task of working as the board's liaison for this process. --Michael Snow ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Board resolutions (chapters)
On Tue, Jan 20, 2009 at 12:24 AM, Florence Devouard anthe...@yahoo.com wrote: For the sake of clarity, I'd like to ask that a mean is given to recognize that a sub-chapter is a sub-chapter rather than a chapter. If not in the name that we use within ourselves, at least on meta and internal pages. For now, I guess everyone from the house can guess that it is a subchapter, but when we have 50 chapters and 50 sub-chapters, it may not be so easy to deal with. I think there's some confusion between recognition of a sub-national chapter, or a chapter whose purview does not cover the entire nation-state in which they operate, and a sub-chapter, which is a misleading distinction that does not (at the moment) exist. Although there are some common-sense rules when it comes to dealing with chapters organized for a metropolitan area or a politically disputed territory, a chapter is a chapter. Every chapter has unique considerations specific to its social and political circumstances—be it Taiwan, Serbia, Hong Kong, or New York City—but, as far as we're concerned, there's no such thing as a second-class chapter. As chapters grow and evolve, so will WMF policy, but for the time being this is where it stands. Austin Hair Chairman pro tempore Wikimedia Chapters Committee ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
