Commons:Projeto plano

This page is presently inactive and retained primarily for historical interest. If you want to revive discussion regarding the subject, you may try using the talk page (though your voice may not be heard) or start a discussion at the Village pump.

Se pretender saber sobre o que é o âmbito da Wikimedia Commons, é provável que esteja à procura de Common:Âmbito do projeto.

---

The goal of the Wikimedia Commons project is to provide a central repository for free images, music and, possibly, texts and spoken texts, to be used by all Wikimedia projects. The Commons was originally proposed by Erik Möller on March 19, 2004 [1]. This is a more elaborate description of the project and its goals based on that proposal and subsequent discussion. It can also be considered a more advanced stage of the ideas tossed around on m:Wikimagery.

Rationale

Currently each of the many Wikimedia projects -- every single Wikipedia and Wiktionary, as well as Wikibooks, Wikisource and Wikiquote -- has a separate directory for file uploads. There is no reliable way to reference images on other projects. Many good, free uploads on one wiki may go unnoticed on another. Thus, there is needless duplication of intellectual and creative work as well as unnecessary redundancy and increased maintenance.

Other advantages:

• Central place to resolve licensing issues
• Less time wasted on locating relevant files
• A place for things like image galleries that go beyond the needs of a single article (e.g. 10 different pictures of the same airplane)
• We can actively solicit contributions specifically to the commons from people who are not interested in contributing on a regular basis
• We can provide the largest such repository of freely licensed material, with a quality control mechanism that other such projects lack (the community)
• We further establish our reputation beyond the encyclopedia projects.
• We benefit from the positive connotations of the term "commons" and appeal more directly to altruism, which will be beneficial when we ask for donations
• We create a very real consciousness for the copyleft idea which so far is missing especially for images, where many people simply upload whatever they find on the net.
• We can use this platform to become more politically relevant in the ongoing discourses about copyright law.
• The "modern" image format SVG allows the bitmap data to be on one location, and e.g. the localized image text on another.

Naming

Wikipedia describes a commons as a "set of resources that a community recognises as being accessible to any member of that community." Such shared resources - forests, fields, fishing grounds, and so forth - have existed in many societies: ancient, medieval, and modern. In Germany, after the Middle Ages, the local commons (Allmende) in most towns and cities were confiscated by the feudal rulers of the regions, which was one of the motivations behind the German Bauernkrieg (war of the farmers against their rulers). The farmers were brutally suppressed, and the commons practically ceased to exist. To this day, descendants of the aristocrats who profited from robbing and murdering the farmers are among the richest families in Germany.

We must make sure that a true commons can exist in the digital age, and that it can never be taken away. Open content licenses assure this. For good reason, the Creative Commons licenses are named after the principle of the commons. But it would be sadly ironic if the term "commons" became associated with a single implementation only. Indeed, it would be desirable if there would be many different commons for different online projects -- a Slashdot commons, a Kuro5hin commons, and so forth -- which provide free access to a large set of resources. Establishing this idea, and this vision, this meme, is one of the reasons for the "commons" naming suggestion.

The name commons embodies the most important underlying principle of this proposal. It is not about a particular type of content, it is about free, shared access to useful resources.

Our commons should be called the Wikimedia commons because it is not just used by Wikipedia, but by all Wikimedia projects (and many external ones). Making "Wikimedia" a part of the name also increases brand recognition for our foundation, which is as yet largely unknown.

Proposal

A central repository is to be created at commons.wikimedia.org. It would hold:

• photos, diagrams and other images
• sounds and music
• artistic works
• documents (see below)
• video (within bandwidth constraints set by the community)

The BBC are attempting to make their back catalogue open resource; therefore linking into the creative commons database recently created by Nutch would be a good thing.

All material in the commons would have to be licensed under one of several licenses, not necessarily the FDL, but all allowing at the very least free distribution and commercial use. For texts, modification rights would also be a requirement. [For non-text, incorporation into larger works or collections would be a requirement. -AD] There would be NO fair use material on commons.wikimedia.org.

As documents are currently maintained by Wikisource, this part of the proposal will have to be debated further as soon as the commons goes live.

Criteria for inclusion

Material would be eligible for inclusion in the Commons if it is useful to at least one Wikimedia project. This includes plausible future usefulness.

The Commons Community would define further criteria for inclusion, for example, if a band is notable enough to have an article in Wikipedia, and their tracks are freely licensed, they can be deposited; if a file is highly referenced from the outside and causes unbearable bandwith costs, it can be removed. The larger and more popular a file, the more pressing needs to be its rationale for inclusion.

Discussion at Commons:Criteria for inclusion

Implementation

The proposal requires some changes to m:MediaWiki, although a working version could already be set up with a relatively small amount of new code.

Upload process

The MediaWiki upload form would be completely redesigned. Look at these two mock-ups:

The first selection is whether a file should be uploaded to the commons or to the local wiki (in the mock-up, the English Wikipedia). The commons would always be the default, but the local wiki could be used for things which are useful only to one wiki, or which are not allowed under the terms of the commons. For example, the English Wikipedia allows limited fair use. This option is, however, not available on the Wikimedia Commons upload form.

The second question is whether the user is the creator of the file. If they are, we narrow down the set of allowed licenses to the ones which we prefer, and the user only needs to type a description and is ready to go. We want to make things as easy as possible for original creators. There are a few more questions, however, if the user is not the copyright holder. In this case, they also need to provide source information for the image.

Note that in these mock-ups, depending on the answer to the "Are you the original creator?" question, the other part of the form is grayed out and not editable. This should make it relatively intuitive.

For another example of what the upload forms could look like, with form text translated into a number of major languages, see m:Translation/New upload form.

The commons wiki

The commons wiki itself should of course be multilingual as Project Sourceberg and Meta are. New uploads would show up both in the upload log of the wiki from which they were uploaded, and in the commons upload log. Without a m:single sign-on, such uploads would be logged as "Username@wiki", e.g. "Eloquence@enwiki".

There would have to be a real commons community, which would take a look at uploaded files, provide translations of image descriptions, sort media files into galleries, translate and annotate source documents, and so forth. They would also be responsible for enforcing the standards of inclusion.

Usage

Usage of material from the commons needs to be largely transparent to the end user. In effect, when a user types

[[Image:Mona Lisa.jpg]]

that request would go first to the local wiki and then, if no local copy exists, to the commons.

The image description page would transparently be imported from the commons everytime it is viewed, until it is edited, at which point a local copy would be created.

Necessary MediaWiki changes

These are some features which we should enter into the m:MediaWiki roadmap if we want to implement this proposal:

• Provide an interface to a shared media file directory, and to the commons wiki database (to update the commons upload log, create image pages etc.)
• Redesign upload form and resulting description pages, allow uploading either to the commons or to the local wiki
• Transparently import pages when viewing commons image pages, permanently import them when editing them

Desirable MediaWiki changes

These changes are not crucial to make the Commons work, but are desirable in the long term:

• Rename the Image: namespace to File: and revamp "image" pages to be more intuitive (allow playback of media files, for example)
• Better interlanguage handling in a single wiki installation
• Friendly user interfaces for multi file uploading
• Selectable categories for images?
• Automatic gallery generation for multiple images
• Transclusion of text from the commons (smart caching!), including individual sections

Commons as basis for single sign-on?

Since the commons proposal requires a shared database (it would be possible to access it via HTTP, but since the Wikimedia setup allows for a shared DB, that would seem unnecessary) it would only be logical to use the commons as the basis for single sign-on.

The implementation would be as follows:

• A field user_created is added to the user table. For existing accounts, this field is filled with the date of the first contribution of the user (alternatively, the date of the creation of their user page). If neither exists, the date is set to "today".
• A new table usermatch is created in the database of each wiki with the fields "local_id" and "commons_id".
• Two tables are created in the commons database: user and user_old.
• The first user_id in the commons user table must be higher than the total number of users of all projects (to avoid attribution problems)
• All unique existing accounts are loaded into the commons user table. An account is unique if it exists only with the same password across all wikis.
• All other existing accounts are loaded into the user_old table, which may include duplicate rows.
• On the creation of a new account that does not exist in the user table, the system system checks whether the account exists in user_old. If so, it prints the name of the oldest account (e.g. "Eloquence, English Wikipedia: 2002-xx") and asks the user for the password to that account.
• If the password is entered correctly, the user now owns that account in the commons database.
• The user can "hook up" additional old accounts by entering the account password. This would be done through the user preferences.
• The edits associated with hooked up accounts would be reattributed using the usermatch tables of the respective wikis. In cases where the usernames are different, a developer would have to push a button -- such cases require changing the user_text in the CUR and OLD table of the respective wiki, which can be quite a big operation.

In the long term, we should of course get rid of the usermatch table and also the user_old table, if possible. Hopefully there will only be relatively few duplicates that do not belong to the same users.

This approach has one key advantage, it quite securely prevents account hijacking. For most users the transition would be completely transparent. The most painful cases are those where a user is forced to change their name because it is already taken by an older user. They are painful largely because of our database layout.

To the end user, it makes things a little simpler, because they can see all the edits they've ever made on all wikis. It may also make stewards obsolete, because bureaucrats can have their status transferred to all wikipedias on which they have an account so they don't have to get them individually (of course, stewards still have the almighty power to desysop someone).

From a technical perspective, the implementation is not so difficult. The filling up of the required tables and fields might take some time, but could be done on a slave database. Using the shared database for logging in is trivial, a universal cookie might be a bit more difficult across different domain names.

Who wants to help?

If you want to help with the implementation of the Wikimedia Commons, please list your name below and describe what you want to do:

• Jober Corrêa
  • Editing Videos. Coordination from Projects involving Broadcast and productions
• Eloquence
  • Coordination and coding. If nobody else does anything, I'll at least implement the basic requirements.
• James Johnson
  • Uploading pictures, texts, etc. from around the web. I'm best with scientific texts/pictures and politics, but I can get other sorts of text/graphics. Administration and localization as well.
• Andre Engels
  • Content, policy, coordination, bot assistance. I could also work with my bot to copy existing images from other Wikipedias. I still strongly object to your time path though.
• Secretlondon
  • Mainly content - I'm not a coder. However I will certainly help with non-coding things.
• Oldak Quill
  • Largely content, co-ordination, administration, interface, policy development. This is a supreme idea, absolutely wonderful.
• Imran
  • Content, co-ordination, establishing relationship with other copyleft content organizations/sites. Could probably do coding if needed.
• Yann
  • Content, localisation, co-ordination.
• Guaka
  • Content, possibly coding.
• VampWillow
  • Interface, 'seek and replace'ing of content
• Angela
  • Policy making, and collaboration with similar projects.
• Davodd
  • Content, policy research, administration; if needed.
• GerardM
  • Content, ideas, footwork
• Neutrality
  • Content.
• Grunt
  • Putting together the framework (whatever you want ot call that), administration (and other maintenance), content.
• Yongliu
  • administration,policy development,Chinese translation coordination
• Fruggo
  • Content, policy making.
• Javier Carro
  • Content, translation into Spanish, sharing of ideas.
• Conti
  • Content, maintenance/administration
• TeunSpaans
  • Flowerpix, mainly.
• Ellywa
  • My own pictures as I add to articles to the Dutch wikipedia. Maybe paintings and other art from open sources.
• Andrewa
  • Use Wikimedia Commons myself for new photos and scans and contribute (hopefully constructive) suggestions based on my experience. Copy my own contributions from English Wikipedia.
  • Try to develop expertise at using it well, and be available to help others do this too.
• Ilyanep
  • Since I don't have too many programming skills, just making suggestions and possibly help with the transition later.
• Gerrit
  • Content, and I could help writing bots, I have enough Python experience.
• Ausir - moving stuff here from Polish Wikipedia
• Netoholic (simple,en)

  Promoting of Simple: as the first Wikipedia to use the Commons exclusively, since Simple: articles should be as freely distributable as possible, as well as easy to translate to other language Wikipedias.

• R.Mayooranathan - Mainly Content, if any multi lingual input necessary I can help with Tamil.
• Nadavspi - Content, translation into Hebrew and Esperanto, maintenance.
• Fantasy - If there is any help needed, just let me know :-)
• Ravip
  • Any possibilities for integration with MIT's front end for media in educational use, metamedia
• Ludraman | T
  • Content
• Farside
  • Translation into Finnish, translation coordination if neccessary
• Quadell
  • Uploading content, quality control, misc tasks
• ZendarPC
  • Interface design and content
• Schaengel89 @me
  • First: translating "commons-pages" into german, then: administration, uploading images from wikipedias and category-building, but I'm not a coder
• Hyacinth
• Huebi DB Design, Programming (PHP), Pojects: a better form for uploading images, making categories available in more then one language
• Henrik Pictures, Grafiks, Content and some Translation.
• WolfgangW. Beeing a „very beginner“ at Commons, I'd like to contribute to simple step-by-step userguides on a beginner's level, e.g. de:User:W./Bildertutorial/1.
• User:Logical1004 : Uploading pictures, from around the web to help in understanding the wiki articles in more clear way.

Policy Debating

Before this project is implemented a simple policy needs be laid down, please debate, discuss and poll on one of the following pages.

Commons:Criteria for inclusion - should pornography be allowed? etc.

Commons:Licensing - should we allow fair use? etc.

Commons:Features - suggest the mechanism, how should it work?

Collaboration with other projects

See Commons:Collaboration with ourmedia.