Hi all.
The page with a frame for cities' applications (I can't find a good
word for that?) is now ready. Please copy/paste the content as
indicated on the page to present your city's application.
Page is here: http://meta.wikimedia.org/wiki/Wikimania_2006/Official_requirements_for_pot…
Applications must be in by the 30th of September. Please note that
this is a wiki, so applications will only be considered "finished" on
the deadline date, you can of course work on meta to make your
application grow. Please leave comments to the talk page so as to
leave the characteristics of the city applying clear. :-)
And as we say in French, "Que le meilleur gagne !"
Best,
Delphine
--
~notafish
The reasons that I'm pushing for a seperate domain for Wikijunior is:
- We need a stable version for kids, that kids and adults alike can't
vandalise.
- We need a more kid-friendly skin and navigation for the MediaWiki, so
curious kids don't get sidetracked in "Recently uploaded images" and the
like.
- We need more attention for the project. We've got at least 55 contributors
just to the Solar System book, which is fantastic, but we need perfection.
As Wikijunior develops past say, 50 books, we would benefit from a seperate
editing wiki. While we're creating seperate and publishable reference works,
the ability to merge them into one greater encyclopedic form.
On Robert's suggestion of Wikijunior being a "stealth" proposal, we've been
around since mid-2004, I've had something relating to the project docked on
the front page of the English Meta essentially daily since then, and the
publicly accessible Board meeting minutes mention the creation of the
project.
As for the assumption this is a pet project of "some board members", they've
certainly helped us with their say in discussions and votes, but so have
many, many other people.
Nick/Zanimum
I've read the recent discussions on new project policies, and it seems
that there is somewhat of a consensus that focusing on the existing
projects is more important than recruiting new ones. I agree with this,
but I also think that this should not prevent us from working on some
policies for the future, as least on the question of licensing.
I participate in the WikiTree project [http://wikitree.org], and we're
seeing some success and popularity. Before we get too big, though, we
would like to know if there is any licensing policy that would be an
issue if we later would like to become a part of WikiMedia. We're
currently BY-NC-SA, and a license switch would essentially force us to
erase all data and start over. As such, we'd like to get it right.
>From an informal poll
[http://wikitree.org/index.php?title=WikiTree:License_poll], it seems
that most people support a liberal license, mainly either Public Domain
or GFDL. Would either of these be a good choice, and would they allow us
to participate officially in WikiMedia in the future? Or would something
else be more appropriate?
I look forward to your comments, either here or on the License Poll page
linked above.
- Joel
I'm reposting here a comment that was posted in
[[b:Talk:Wikijunior]]:
During the upcoming September 18 Wikimedia
Foundation board meeting,
the Board will discuss registering a seperate
domain for Wikijunior,
presumably wikijunior.org. Presumably Wikijunior
will still be
developed on Wikibooks, but it will go live on a
seperate site.
Alternatively, we could have en.wikijunior.org for
viewing, and
en2.wikijunior.org for editing, which would allow
for a greater ease
in developing pages, as they could be part of a
freeform
encyclopedia (on limited topics), rather than the
isolated books
they are now. If we were to develop off Wikibooks,
I'd like us to
retain most, if not all of the structure of
Wikibooks, it's worked
well so far. -- user:zanimum
<http://en.wikibooks.org/wiki/User:Zanimum>
What I'm asking is why such a proposal is not going
through the normal
vetting process required of any new project proposal
or is Wikijunior
already considered to be a Wikimedia sister project
already? I
appreciate the efforts of Zanimum, but I certainly
think that before a
new project domain is started, the full extent of an
idea like this
should be fully vetted, and even a formal vote should
take place, like
happened to Wikinews and is going to happen soon with
Wikiversity. The
purpose of the vote is to mainly get a show of support
for the project
(I have no doubt that there is some major support from
several people on
Wikibooks, for instance, regarding Wikijunior). The
vote also help
critics to try and correct major problems with the
proposal. In
particular, there doesn't even seem to be any movement
at all on
Wikibooks to get rid of Wikijunior, and it pretty much
stays in its own
little corner of Wikibooks quietly undergoing a
metamorphisis, such as
the current content clean-up campaign on the
Wikijunior Solar System at
the moment.
This amounts to, IMHO, another stealth new project
proposal that is
going through the back door. I've complained enough
about the new
project proposal process here that I've had people
telling me to
essentially shut up and don't bug people on this list
about it. At the
same time, I think projects like this need more work
on how everything
is going to be put together before it should be
started on its own
seperate wiki, and I've seen no reason why Wikijunior
should get any
special attention other than it seems like a pet
project of some board
members.
--
Robert Scott Horning
---------
A pet project of who ?
I doubt very much the decision of creating or not
creating a new wikijunior project will be taken during
that meeting. If it does, it will not be following
policy, so will be invalid.
Hmmm, first, I am just discovering this on the agenda
(I heard recent discussions here and there about this,
but absolutely not involving the board itself).
Second, and most important, there are written rules
for proposal of new projects (I think I authored a big
part of it), these are generally approved and they
absolutely not make it possible for the board to just
decide alone such a creation. See
http://meta.wikimedia.org/wiki/New_project_policy
(note with attention the little paragraph about
closing projects. Thanks).
Third, I believe that any participants of the meeting
are aware there is no way such a decision should be
taken by them. This, regardless of them being board
members, officers or chapter members. First, because
the policy mentions only two bodies, board of
Foundation and community. Second because chapters do
not have "power" over content". And we all know this.
So, a vote during the 18th of september to decide a
creation or not just does not make sense.
So, please do not worry about that :-)
However, it could be a topic of discussion :-)
Anthere
PS: since you mention you do not support current
policy for new project proposal, please take the time
to explain why here :
http://meta.wikimedia.org/wiki/Talk:New_project_policy.
There are no comments from you right now. Please
provide feedback on what you do not appreciate. Not
that this policy was set up after the Wikispecies
fiasco, to avoid this from happening again. So, while
my policy proposal was probably not the best one we
could think of, it was certainly better than nothing.
It has already been followed for wikinews and now will
be for wikiversity.
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
Ashar Voultoiz wrote:
> As I understand your plan, 'Wikimedia web' product on bugzilla will be
> closed/deleted and bug moved to otrs.
i've created a new bugzilla product, "Issues". i don't think "Wikimedia
websites" will disappear, since it's still a reasonable method to report
problems, whereas Issues is only editable by developers.
bugs get opened in issues when someone sends a problem report to OTRS.
at the moment they're assigned to me, but i'll probably create another
mailing list (announce-only, like wikibugs-l) for it.
> What about an issue reported to
> the noc that then need to be moved to bugzilla ?
someone can open a bug in bugzilla on behalf of the person who mailed
noc about it. (or just tell them to do that.. as long as it gets moved
somehow).
> Looks like dev/sysadmin will have to look at both interfaces if they
> want to get the full history of the problem.
well, the idea is that only one person has to look at OTRS, and any
other developers can see all current issues in bugzilla (via the Issues
product). the reason i used OTRS for that is to act as a 'filter'
between users reporting problems, and extracting actual issues which
need to be solved from that.
> You can probably set up bugzilla to have several virtual admin teams
> (dns, squids, apaches, hardware, kennisnet). All new messages could be
> assigned to the issue manager with an 'unconfirmed' status he will then
> give out the bug to one of the virtual teams that can then deal with the
> problem.
would each team be a mailing list? i was thinking of an all-developers@
list to assign bugs to by default (at the moment they're assigned to me,
but that's not a very good solution).
> > the issues manager can then formulate a list of tasks required to resolve each
> > issue, and place them on a wiki page somewhere (probably split by particular
> > people, and tasks for all developers). there's then a central place to look to
> > know what needs to be done. further, this can be used to produce a list of
> > open and resolved problems on the site, and what was done to fix them, to keep
> > users and the board better informed of what's going on. (for example, a weekly
> > 'issues summary' mail to the list).
>
> Isn't what http://wp.wikidev.net/ is for ? Some troublechecking guide
> would probably be useful.
i was going to use wikidev for it, but i think it's more useful for that
to go on bugzilla now. of course, documenting things on wikidev is
still a good idea ;-) (and the server admin log shouldn't go away).
> > this can also be used as central point of contact for communications with
> > outside partners, such as Kennisnet and Lost Oasis (although purely for
> > technical matters, not negotiations).
> Just one last thing: what about issues being reported on IRC ? Should
> users be redirected to the new interface ? If so we might as well
> moderate the channel.
well.. if people want to report issues via IRC, it's fine, but i think
the general attitude should be that if it's not sent to noc@, there's no
guarantee it'll get fixed. the user doesn't have to do that, of course
- a developer who happens to be on IRC, or whatever, can open a new
ticket. i definitely don't want to start ignoring people trying to
report problems, however they do it, since the idea of this is to make
it _easier_, not _harder_...
kate.
Hi
I have installed mediawiki version 1.4.9 successfully in a linux server.
MediaWiki <http://wikipedia.sf.net/> (*http://wikipedia.sf.net/*): 1.4.9
PHP <http://www.php.net/> (*http://www.php.net/*): 4.2.2 (apache2filter)
MySQL <http://www.mysql.com/> (*http://www.mysql.com/*): 4.0.17-standard All
works fine but EDITION toolbar, it is not displayed
I have enabled in preferences "show edition toolbar"
I have enable JavaScript in FireFox and Explorer
And at the end no one can see edition toolbar.
Later I made a new clean installation of mw1.4.6+enotifwiki3.11 and the
problem is the same, all works fine but edition toolbar is not shown.
Any idea?
Dear "Foundation" members,
I'm a very recent newbie so I apologize in advance for asking questions that
are already answered on Wikipedia. My only excuse is that I've not been able
to find them. With a whole 24 hours of Wikipedia experience under my belt,
I'm interested in the following points:
1. My first impression is that the priorities for adding or improving
Wikipedia content are mainly "contributor-driven". I'm not sure whether this
is correct. The statistics pages mainly show the growth in Wikipedia users
and the content added during the past months & years. Do we also have some
statistics showing things like hits per page and also "non-hits"? In other
words, content that non-contributing users would like to have found but
didn't? Have we carried out surveys amongst non-Wikipedians to find out what
they (potentially) would be interested in finding out at Wikipedia? I guess
I'm looking for some kind of handle to distinguish between what contributors
would like to see improved and what non-contributors would like to see
improved.
2. Is there any kind of policy or marketing group that adresses the issues
in point 1.
Thanks in advance for your time and effort in answering this e-mail.
Hopefully you can point me to the right pages and/or lists.
Idaho 2000
I'm reposting here a comment that was posted in [[b:Talk:Wikijunior]]:
During the upcoming September 18 Wikimedia Foundation board meeting,
the Board will discuss registering a seperate domain for Wikijunior,
presumably wikijunior.org. Presumably Wikijunior will still be
developed on Wikibooks, but it will go live on a seperate site.
Alternatively, we could have en.wikijunior.org for viewing, and
en2.wikijunior.org for editing, which would allow for a greater ease
in developing pages, as they could be part of a freeform
encyclopedia (on limited topics), rather than the isolated books
they are now. If we were to develop off Wikibooks, I'd like us to
retain most, if not all of the structure of Wikibooks, it's worked
well so far. -- user:zanimum <http://en.wikibooks.org/wiki/User:Zanimum>
What I'm asking is why such a proposal is not going through the normal
vetting process required of any new project proposal or is Wikijunior
already considered to be a Wikimedia sister project already? I
appreciate the efforts of Zanimum, but I certainly think that before a
new project domain is started, the full extent of an idea like this
should be fully vetted, and even a formal vote should take place, like
happened to Wikinews and is going to happen soon with Wikiversity. The
purpose of the vote is to mainly get a show of support for the project
(I have no doubt that there is some major support from several people on
Wikibooks, for instance, regarding Wikijunior). The vote also help
critics to try and correct major problems with the proposal. In
particular, there doesn't even seem to be any movement at all on
Wikibooks to get rid of Wikijunior, and it pretty much stays in its own
little corner of Wikibooks quietly undergoing a metamorphisis, such as
the current content clean-up campaign on the Wikijunior Solar System at
the moment.
This amounts to, IMHO, another stealth new project proposal that is
going through the back door. I've complained enough about the new
project proposal process here that I've had people telling me to
essentially shut up and don't bug people on this list about it. At the
same time, I think projects like this need more work on how everything
is going to be put together before it should be started on its own
seperate wiki, and I've seen no reason why Wikijunior should get any
special attention other than it seems like a pet project of some board
members.
--
Robert Scott Horning
Hi,
> That is a technical issue, not a policy one. My suggestion is for the
> German chapter to act on one of their hosting offers, buy a bunch of
> servers to use as squids and then we can work out the ownership
> issues later.
A bunch of squids? We have a bunch of squids in Europe.
We do not need more. Serving the web site is not just about caching :)
> Not a shortfall. A squid in Germany will negate the need for
> buying one in Florida. The budget is based on needs;
> it is even likely that if the Yahoo! servers go online this quarter,
> then that will negate the need for buying a whole bunch of servers.
> The money saved would then roll-over into the next quarter's budget.
We do not buy more squids for Florida. We buy more database and
application servers. Squids ain't any magic, they cache what is cachable,
all other web content has to be generated. Including your stub colors.
On the other hand, we're growing much faster than we could ever split.
Korea would be our testbed for splitting (at least we would not understand
user troubles in their native languages :) off Asian wikis.
Please note, that there are different load patterns out there. Instead of
having multiple sines (local load patterns) covering each other, we'd
have to maintain separate sines, with lots of unused capacity. We
have to really understand how splitting our website would affect our
performance. And how manageable it would be afterwards.
The only way to really start e.g. European deployment, is to
put at least 200k$ in there. But that won't be worth 200k$ spent in
Florida. Or maybe even 100k$. Wikimedia cluster is already a
platform of scale. We just do not want to have more resource-bound
Deployments, as they are real PITA to manage.
Or as I told before - we may establish quarterly performance goals and limit that.
We may explain concepts of SLA and stuff. You would not want that. And it is
impossible to try out new concepts for wikis at all while operating in
maxed out environment.
It was rather difficult for me to express what we need
for the site with current budgeting practices. But I'd really love to go
towards such hardware purchase:
200 dual opteron multi-purpose servers, ~2.5k$ each.
20 data management servers, ~15k$ each.
Additional networking/support gear, ~50k$
So by the end of this year we could have a nicely functioning cluster.
And I hope it wouldn't be that loaded until then. Or else we'll come up
with multi-million budget.
We are running a website after all. A big website. A complex website.
There is no magic in there, there are resources and resource shortages.
And... We're still growing. If anyone comes with a nice optimization idea
(we have heard some, ..), they can sure tell it. But for a while we will need
resource expansion, whatever 20% or 50% wins are gained. So, if we can,
let us not forget that.
Cheers,
Domas