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
hello.
we currently have some problems with identifying current issues on the site, and
knowing what needs to be done, and so on. i've decided it would be a good idea
to spend some time on 'management' stuff like this, so i'm trying to come up
with a suitable procedure to make sure things work smoothly.
as such, i'd like to propose a new way to manage issues:
the primary point of contact for site issues will be the existing NOC ticket
system, noc(a)wikimedia.org. users should mail this address with any technical
issues *relating to the Wikimedia sites* (i.e., it does not replace bugzilla for
MediaWiki). confirmed issues will be moved to the new "issues" queue by the
"issues manager" (well, you know everyone needs a title). this will also apply
to requests from developers; for example, things that need to be done by the
on-site developer (previously Chad), and other developers (paid developers in
particular).
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).
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).
unless anyone has strenuous objections to this, i'd like to try it immediately;
we can see how well it works, or whether anything needs to be changed. as i'm
not doing much actual developer work recently, i'll probably take on the role of
issues manager...
any comments appreciated.
regards,
kate.
An open Wikimedia meeting will be held on IRC today.
An agenda is at
http://meta.wikimedia.org/wiki/Board_agenda#August_week_4 - please
suggest additions on the talk page.
So far, the agenda includes:
# Status of Wikicouncil
# Wikinews: license and Chinese version
# Seed wiki for potential new projects
# Possible wiki closures: Simple, Klingon, Sep11, Others...?
If you are interested in any of these topics, please come and give
your opinion during the meeting.
The meeting will be in #wikimedia-meeting. For anyone without an IRC
client, I've created a temporary CGI gateway at
http://irc.wikicities.com/meeting/
The meeting starts at 20:00 UTC
(<http://meta.wikimedia.org/wiki/Timezone_conversion>) and should last
no more than two hours.
Angela.
Finally new wikistats
See http://mail.wikipedia.org/pipermail/foundation-l/2005-August/004043.html
for an explanation why they could not be run for so long.
For some projects, like wikipedia, the newest dumps are already 6 weeks old.
Please don't ask me for next update, as it is not in my hands.
Data for French and German wikipedias are missing.
For French I will have to look into why the job failed.
For German the full xml database export is corrupt.
Erik Zachte