We'll be holding a public IRC bug triage in about 2-3 minutes on
#wikimedia-dev for all who are interested. We will be using
http://etherpad.wikimedia.org/BugTriage-2011-06 to keep notes as well.
See you there!
Mark.
Hi;
@Derrick: I don't trust Amazon. Really, I don't trust Wikimedia Foundation
either. They can't and/or they don't want to provide image dumps (what is
worst?). Community donates images to Commons, community donates money every
year, and now community needs to develop a software to extract all the
images and packed them, and of course, host them in a permanent way. Crazy,
right?
@Milos: Instead of spliting image dump using the first letter of filenames,
I thought about spliting using the upload date (YYYY-MM-DD). So, first
chunks (2005-01-01) will be tiny, and recent ones of several GB (a single
day).
Regards,
emijrp
2011/6/28 Derrick Coetzee <dcoetzee(a)eecs.berkeley.edu>
> As a Commons admin I've thought a lot about the problem of
> distributing Commons dumps. As for distribution, I believe BitTorrent
> is absolutely the way to go, but the Torrent will require a small
> network of dedicated permaseeds (servers that seed indefinitely).
> These can easily be set up at low cost on Amazon EC2 "small" instances
> - the disk storage for the archives is free, since small instances
> include a large (~120 GB) ephemeral storage volume at no additional
> cost, and the cost of bandwidth can be controlled by configuring the
> BitTorrent client with either a bandwidth throttle or a transfer cap
> (or both). In fact, I think all Wikimedia dumps should be available
> through such a distribution solution, just as all Linux installation
> media are today.
>
> Additionally, it will be necessary to construct (and maintain) useful
> subsets of Commons media, such as "all media used on the English
> Wikipedia", or "thumbnails of all images on Wikimedia Commons", of
> particular interest to certain content reusers, since the full set is
> far too large to be of interest to most reusers. It's on this latter
> point that I want your feedback: what useful subsets of Wikimedia
> Commons does the research community want? Thanks for your feedback.
>
> --=20
> Derrick Coetzee
> User:Dcoetzee, English Wikipedia and Wikimedia Commons administrator
> http://www.eecs.berkeley.edu/~dcoetzee/
>
>
At least 1 BDS Activist has been running around on twitter telling people not to go to wikimania.
http://twitter.com/_____C
Our article on BDS:
http://en.wikipedia.org/wiki/Boycott,_Divestment_and_Sanctions
BDS view and action on wikimania:
http://www.alternativenews.org/english/index.php/topics/economy-of-the-occu…
In particular, they state:
" On the information page for the upcoming conference, the organizers also say, “Haifa is also easily accessible to the Palestinian
community, which is often left out of conferences such as Wikimania due to special difficulties. This community has a high rate of
Internet usage but little first-hand acquaintance with Wikipedia and other Wikimedia projects.”
The statement, however, is not true. Participation for individuals from Gaza and the West Bank is impossible, unless they receive
special permits from the Israeli military to enter Israel in order to attend."
To be able to actively counter this claim, can we confirm that all palestinian wikimedians who want to come are indeed coming?
sincerely,
Kim Bruning
--
[Non-pgp mail clients may show pgp-signature as attachment]
gpg (www.gnupg.org) Fingerprint for key FEF9DD72
5ED6 E215 73EE AD84 E03A 01C5 94AC 7B0E FEF9 DD72
You don't have to have an account on LinkedIn to receive these emails. We
were getting them sent to OTRS email addresses all the time before I asked
LinkedIn to block emails to the addresses. Had to go through customer
service because they don't provide an opt-out link in the emails they send.
We still get some to a few addresses I asked to opt out of. I thought I
also asked the list to be opted out as well, but potentially they received a
bounce email back and so disregarded the ticket.
The main concern is people need to stop uploading their contacts lists and
then telling LinkedIn to invite *everyone* in it. Take the time to select
actual individuals rather than spamming everyone.
Board has decided to make Closing projects [1] official. The text of the
policy is below (as well as at the mentioned page).
Language committee members who decided to take care about this would be
listed inside of the section "Tasks" of the members list [2]. During the
next weeks present requests will be normalized after the discussion at
the LangCom list.
[1] http://meta.wikimedia.org/wiki/Closing_projects_policy
[2] http://meta.wikimedia.org/wiki/Language_committee/Members
* * *
This policy proposal defines the process to close (and in some
situations delete) a wiki hosted by the Wikimedia Foundation. The
proposals are handled by [[Language Committee]] members who opt-in to
take care of this, and the [[Board of Trustees]] has final authority
over the member's decision.
==Problem situation and new authority==
The current [[Proposals for closing projects]] lack a clear policy.
Several proposals have been made for a policy, but so far none has been
adopted.
Because of that, a lot of small inactive wikis are proposed to be
closed. Some people support out of principle ("wiki is inactive"), while
others oppose out of principle ("let it grow"). Often, users came by and
made a decision, which could even be the opposite of the actual consensus.
This policy tries to address this problem by:
* requiring a valid reason for closure, and defining several reasons as
either valid or invalid reasons
* putting the procedure in hands of language committee members and final
Board decision
The community has no longer authority over closing projects, but only an
advising task. This puts the procedure in line with the [[language
proposal policy]], which is also dependent on language committee and
Board approval. That means closing projects is no longer easier than
opening one.
Although the decision is made by a member of the Language Committee and
no longer through community consensus, the Board will have final
authority, and the LangCom is convinced that this procedure will improve
the decision-making and that both the LangCom and the Board are the
appropriate authority for dealing with closing Wikimedia wikis.
==Policy proposal==
===Types of proposals===
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:
# Regular language editions that are small/inactive but do not generally
harm to stay open (automatic spam is always blocked, contrary to the past).
#: ''For example: Afar Wiktionary, Gaeilge Wikiquote, Guarani Wikibooks,
...''
# Other (often relatively more active) wikis that may be controversial,
questionable or in another way uncommon.
#: ''For example: Quality Wikimedia, Simple English Wikiquote, ...''
===Definition of actions===
* Closing a wiki means locking the database so it cannot be edited but
all pages are still visible to public. User rights (sysop, ...) are
removed and can be restored on user request when the wiki is re-activated.
* Deleting a wiki means deleting the database so it is completely
unavailable on the web. An XML file with the wiki's content will still
be available for external use.
* Transferring or importing content means moving useful articles/pages,
along with the contribution history, to the [[Wikimedia Incubator]],
[[oldwikisource:|OldWikisource]] or [[betawikiversity:|BetaWikiversity]]
(or another site when explicitly mentioned). <small>See
[[incubator:I:Importing]] for more info.</small>
** Files are left on the wiki because of a lack of an export function.
When the wiki will be deleted, files could be downloaded manually if
needed. <small>When such a software feature becomes available, files
should be exported.</small>
===Proposing===
Anyone can propose to close a wiki. The following must be done:
* The proposal must be categorised under either type 1 or type 2 (see
above).
* If you want the wiki to be deleted as well, that must be explicitly
mentioned in the proposal.
* When the proposal is submitted, the local wiki should be informed as
soon as possible.
* A good reason should be given why it should be closed/deleted.
** Inactivity in itself is ''no'' valid reason; additional problems are.
When the Wikimedia Incubator is at a stage where it is usable to a
certain extent like a real wiki<ref>In the future, the Wikimedia
Incubator is intended to function as a place for normal wikis that are
not large enough to need an own wiki (so we don't have a large number of
small wikis but instead a normal Incubator wiki with "virtual
wikis").</ref>, inactivity will be a valid reason.
** Absence of content since the wiki's creation is a valid reason
(usually for type 1).
** Not meeting the current [[WM:LPP]] requirements is ''no'' valid reason.
===Decision===
* During a period of 30 <small>(''can be changed'')</small> days, the
proposal is public to the community for comments and recommendations.
* Any Language Committee member who has opted-in to take care of
handling closing projects proposals can bring up the proposal on the
mailing list. It is discussed during 15 days (or longer if needed),
without formal voting.
* Thereafter, the initial LangCom member makes a decision and sends its
recommendation to the [[Board]] which has final authority.
===Proposal approved===
* For the first type of proposal, useful content should be transferred
to the Incubator. Whether content is useful is hard to define, but
common sense can help. For the second type, a different solution for the
content is often appropriate.
* A bug should be submitted to Bugzilla to request the closure (and
deletion if applicable).
* Re-opening projects is done through [[requests for new languages]],
which uses the [[Meta:Language proposal policy]] that is much more
strict than used to be in the past (when most wikis that are now
proposed for closure, were started)
===Proposal rejected===
* The wiki remains open.
* A new proposal may be submitted if there are new conditions. A
proposal that is exactly the same, may not be made the same year to
reduce unneeded duplicate proposals.
==Retroactivity==
As has been done when the Langcom policy was introduced, all current
proposals will be made invalid. Anyone can start a new proposal under
the new policy.
==References==
<references />
==Links==
* http://noc.wikimedia.org/conf/closed.dblist – automatic list of
currently closed wikis
* [[bugzilla:28985|Bug 28985]] – Wikis ready for closing (tracking)
* Previous proposals
** [[Closure of WMF projects]] (August 2008 proposal)
** [[Closing/Deletion project policy]] (2006 proposal)
* Other
** [[Proposals for closing projects]]
** [[Proposals for closing projects/General discussion about small,
inactive wikis]]
** [[Requests for comment/Rights and closed wikis]]
I also agree that a resolution is needed. Two individuals don't speak for
the whole board and I'm not willing to take your word on it. Up until now
the community has had the say over which projects were closed through the
proposals for closing projects and you throw out the statement that there's
a new "policy" that's "official" with nothing to back it up. Further it's
supposedly the language committee which should have the say when most of the
proposals for closure are due to inactivity and have nothing to do with the
language itself.
I never saw any requests for comment from the community either before you
decided to pull the rug out from under us. The situation is ridiculous.
> From: Milos Rancic <millosh(a)gmail.com>
> To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
> Date: Sat, 25 Jun 2011 13:04:50 +0200
> Subject: Re: [Foundation-l] Closing projects policy now official
> On 06/25/2011 12:54 PM, Béria Lima wrote:
> > So we should wait for a resolution no? Until there is only your word.
> >
> > PS: I'm not saying you are lying or anything, but that the final decision
> > about that requires a Resolution.
>
> I don't think that it is needed because Board has the final word anyway,
> as well as Language proposal policy has never officially approved as-is,
> but through the general recognition of Language committee.
>
Sue Gardner writes:
> Would inviting Matt to join create perception problems?
> Probably not among external stakeholders because donors serving on
> boards is fairly normal in non-profit land, but yes among community
> members, because the community is (appropriately) a fierce defender of
> the independence of the projects. Should the board do what it thinks
> is best for the organization and the movement, even if its
> decisions/actions are unpopular? The board decided yes. Should the
> board try to separate the grant announcement from the Matt
> announcement to mitigate community anger? No, because that would be
> disingenuous. And, it might actually increase anger rather than
> mitigating it.
>
In my view, Sue has expressed the reasoning of the Board in a nutshell here.
Remember that the
Board recognized the risks of appointing Matt, and nevertheless appointed
him anyway. The community plays a large role in selecting Board members, and
it is appropriate to keep this in mind when voting on Board seats.
Nevertheless, I think the Board made a hugely intelligent and attentive
decision in appointing Matt, and I think it is best if the community
acknowledges and honors that decision, which comes in part from Board
members the community supports.
--Mike Godwin