Hello,
as far as I know there are settings for WikiMedia-projekts that can only be done by certain developpers. An example is the change for autoconfirmed days limit. So if the projects want such a setting changed, it must ask a developper to do that.
Do we have such a mechanism? Where should the project request such a setting and who cares about these requests?
Greetings Ting
On Mon, Jul 7, 2008 at 6:13 PM, Ting Chen Wing.Philopp@gmx.de wrote:
Hello,
as far as I know there are settings for WikiMedia-projekts that can only be done by certain developpers. An example is the change for autoconfirmed days limit. So if the projects want such a setting changed, it must ask a developper to do that.
Do we have such a mechanism? Where should the project request such a setting and who cares about these requests?
Yes, this is done via Bugzilla (bugzilla.wikimedia.org)
Use https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia to enter a new bug and add 'shell' in the box of keywords (towards the bottom)
Michael
On Mon, 2008-07-07 at 18:16 +0200, Michael Bimmler wrote:
On Mon, Jul 7, 2008 at 6:13 PM, Ting Chen Wing.Philopp@gmx.de wrote:
Hello,
as far as I know there are settings for WikiMedia-projekts that can only be done by certain developpers. An example is the change for autoconfirmed days limit. So if the projects want such a setting changed, it must ask a developper to do that.
Do we have such a mechanism? Where should the project request such a setting and who cares about these requests?
Yes, this is done via Bugzilla (bugzilla.wikimedia.org)
Use https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia to enter a new bug and add 'shell' in the box of keywords (towards the bottom)
Michael
For most (all?) changes, the dev will ask for a link to an on-wiki discussion which show the changes being asked for has consensus on that project.
KTC
Thanks for your answer. This process does not seem to work well. Here is an example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14624
Two months already and no response. Also no request for a link. And see the last comment from es-wp, so it seems to be a general problem that can potentially hit every project. My impression is that there are no body who feel responsible for this. If it is so, I think we should set up a responsible person for this. As far as I know it doesn't happen every day and it is surely not a thing that takes a lot of time.
Any opinion or suggestions?
Ting.
-------- Original-Nachricht --------
Datum: Mon, 07 Jul 2008 19:24:37 +0100 Von: Kwan Ting Chan ktc@ktchan.info An: Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org Betreff: Re: [Foundation-l] Process for a project to request a setting
On Mon, 2008-07-07 at 18:16 +0200, Michael Bimmler wrote:
On Mon, Jul 7, 2008 at 6:13 PM, Ting Chen Wing.Philopp@gmx.de wrote:
Hello,
as far as I know there are settings for WikiMedia-projekts that can
only be done by certain developpers. An example is the change for autoconfirmed days limit. So if the projects want such a setting changed, it must ask a developper to do that.
Do we have such a mechanism? Where should the project request such a
setting and who cares about these requests?
Yes, this is done via Bugzilla (bugzilla.wikimedia.org)
Use https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia to enter a new bug and add 'shell' in the box of keywords (towards the bottom)
Michael
For most (all?) changes, the dev will ask for a link to an on-wiki discussion which show the changes being asked for has consensus on that project.
KTC
-- Experience is a good school but the fees are high.
- Heinrich Heine
Ting Chen writes:
Thanks for your answer. This process does not seem to work well. Here is an example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14624
Two months already and no response. Also no request for a link. And see the last comment from es-wp, so it seems to be a general problem that can potentially hit every project. My impression is that there are no body who feel responsible for this. If it is so, I think we should set up a responsible person for this. As far as I know it doesn't happen every day and it is surely not a thing that takes a lot of time.
Any opinion or suggestions?
Ting.
That is from my point of view because of a lack of shell developers we have. Usually Jens and sometimes Brion or Tim handles those bugs, but all of them are very busy, that's why we have such an awful delay. --VasilievVVV
Hoi, I would say that it is a matter of priorities. As far as I am aware the priorities are very much one of:
- KEEP THEM ROLLING - We are volunteers and we do as we like
Consequently, projects can take multiple years, things do not get done or done whenever. When the WMF has more developer capacity, it may make it a priority to prevent these bugs from bugging us.
Thanks, GerardM
On Tue, Jul 8, 2008 at 11:18 AM, VasilievVV vasilvv@gmail.com wrote:
Ting Chen writes:
Thanks for your answer. This process does not seem to work well. Here is
an example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14624
Two months already and no response. Also no request for a link. And see
the last comment from es-wp, so it seems to be a general problem that can potentially hit every project. My impression is that there are no body who feel responsible for this. If it is so, I think we should set up a responsible person for this. As far as I know it doesn't happen every day and it is surely not a thing that takes a lot of time.
Any opinion or suggestions?
Ting.
That is from my point of view because of a lack of shell developers we have. Usually Jens and sometimes Brion or Tim handles those bugs, but all of them are very busy, that's why we have such an awful delay. --VasilievVVV
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Gerard Meijssen writes:
Hoi, I would say that it is a matter of priorities. As far as I am aware the priorities are very much one of:
- KEEP THEM ROLLING
- We are volunteers and we do as we like
Consequently, projects can take multiple years, things do not get done or done whenever. When the WMF has more developer capacity, it may make it a priority to prevent these bugs from bugging us.
Thanks, GerardM
Another option may be to allow stewards to change such configuration using web-interface like Configure [1].
[1] http://www.mediawiki.org/wiki/Extension:Configure --VasilievVV
I would say that it is a matter of priorities. As far as I am aware the priorities are very much one of:
- KEEP THEM ROLLING
- We are volunteers and we do as we like
Consequently, projects can take multiple years, things do not get done or done whenever. When the WMF has more developer capacity, it may make it a priority to prevent these bugs from bugging us.
At first I don't consider this as a bug. So I am a little confused to find it in Bugzilla. It is (for my understanding) a request of a setting.
And I see this as part of KEEP THEM ROLLING.
As I have said, it is not a day consuming thing and it doesn't happen so often. So I suppose it should be possible to name a responsible person to handle this. If a setting is not meaningful, because it is too difficult, or because it is still in testing phase, it would also not be time consuming to add a comment like "This feature is not yet free for every project". People are not angry because they don't get a feature, they are angry because they don't get a response.
Another option may be to allow stewards to change such configuration using web-interface like Configure [1].
This can possibly release such things to the projects. But this extension is not used in our projects, right? Is it then possible that the bureaucrats only can change a bunch of settings or would they have the right to set everything?
Regards Ting
On Tue, Jul 8, 2008 at 2:22 PM, Ting Chen Wing.Philopp@gmx.de wrote:
I would say that it is a matter of priorities. As far as I am aware the priorities are very much one of:
- KEEP THEM ROLLING
- We are volunteers and we do as we like
Consequently, projects can take multiple years, things do not get done or done whenever. When the WMF has more developer capacity, it may make it a priority to prevent these bugs from bugging us.
At first I don't consider this as a bug. So I am a little confused to find it in Bugzilla. It is (for my understanding) a request of a setting.
You're confused about bugzilla. Despite its name it is not only the place for bug reports but also feature requests and site requests.
As someone who has complained about the system in the past, I will explain what I have learned and hope others correct me if anything is in error. First you are looking at bugzilla from the wrong angle. It is not necessarily a mechanism to make certain requests are done so much as one to make certain requests are tracked. To make certain a request is actually done often requires contacting a developer directly and asking him to personally take care of your request linking to the bugzilla page. This personal request may have to be repeated a few times on different occasions till you find a developer at a convenient time. (I have also heard building shrines to these demi-gods is helpful) But all joking aside there is not really any mechanism in place to make sure requests get attention on an organized fashion. It is more a matter of whoever is able to demand attention; receiving it.
Birgitte SB
--- On Tue, 7/8/08, Ting Chen Wing.Philopp@gmx.de wrote:
From: Ting Chen Wing.Philopp@gmx.de Subject: Re: [Foundation-l] Process for a project to request a setting To: "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Tuesday, July 8, 2008, 1:19 AM Thanks for your answer. This process does not seem to work well. Here is an example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14624
Two months already and no response. Also no request for a link. And see the last comment from es-wp, so it seems to be a general problem that can potentially hit every project. My impression is that there are no body who feel responsible for this. If it is so, I think we should set up a responsible person for this. As far as I know it doesn't happen every day and it is surely not a thing that takes a lot of time.
Any opinion or suggestions?
Ting.
-------- Original-Nachricht --------
Datum: Mon, 07 Jul 2008 19:24:37 +0100 Von: Kwan Ting Chan ktc@ktchan.info An: Wikimedia Foundation Mailing List
foundation-l@lists.wikimedia.org
Betreff: Re: [Foundation-l] Process for a project to
request a setting
On Mon, 2008-07-07 at 18:16 +0200, Michael Bimmler
wrote:
On Mon, Jul 7, 2008 at 6:13 PM, Ting Chen
Wing.Philopp@gmx.de wrote:
Hello,
as far as I know there are settings for
WikiMedia-projekts that can
only be done by certain developpers. An example is the
change for
autoconfirmed days limit. So if the projects want such
a setting changed, it must ask
a developper to do that.
Do we have such a mechanism? Where should
the project request such a
setting and who cares about these requests?
Yes, this is done via Bugzilla
(bugzilla.wikimedia.org)
Use
https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia to
enter a new bug and add 'shell' in the
box of keywords (towards the
bottom)
Michael
For most (all?) changes, the dev will ask for a link
to an on-wiki
discussion which show the changes being asked for has
consensus on that
project.
KTC
-- Experience is a good school but the fees are high.
- Heinrich Heine
-- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Tue, Jul 8, 2008 at 2:19 AM, Ting Chen Wing.Philopp@gmx.de wrote:
Thanks for your answer. This process does not seem to work well. Here is an example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14624
Two months already and no response. Also no request for a link. And see the last comment from es-wp, so it seems to be a general problem that can potentially hit every project. My impression is that there are no body who feel responsible for this. If it is so, I think we should set up a responsible person for this. As far as I know it doesn't happen every day and it is surely not a thing that takes a lot of time.
Any opinion or suggestions?
It does take a fair amount of time to handle all the requests promptly, and by all reports it's horribly boring. The basic problem is that with the current setup, anyone with the ability to institute these changes has root database access, which requires an *extremely* high level of trust (since anyone with such access can change anything on any wiki untraceably, including logs and histories). So it's not like a few new people could just be given these rights so they can handle it. It used to be that Brion would reliably fulfill all the shell bugs every now and again, but he's too busy for that these days.
One solution, and probably the most sensible, would be to use an extension like Configure that allows people with much lesser access levels to change these settings. The other would be to assign the job to someone like that new junior developer we're supposed to getting, which is possibly less reasonable but probably easier (once we do get some more tech employees who can be assigned stuff like this).
I think there was recently a thread about the press about the paper A Gene Wiki for Community Annotation of Gene Function [1]. I was reading it today and found it interesting in respect to views generally expressed on this mailing list against bot created articles. Personally I can't see why this sort of work described here should be required to be done by hand (as is the case where some wikipedias don't allow this sort of bot creation). Especially when analysis found that after the bot created stubs for all genes in the authorative database that were missing from Wikipedia, "approximately 50% of all edits to gene pages were made on the newly created pages." There is also interesting argument is made about how the existence of a complete network (even if, as in this case, partially consisting of bot-created stubs) leads to more efficient browing of the entire subject area.
Obvioulsly not all bot creations are equal, but I wonder if the feelings so often expressed against bot creations have more to do with the manner of creating articles than abandoning them (drive-by creation). This project, run by subject experts who are tracking the additional editing to the created articles and courting more activity with papers like this one seem to be a different matter altogether. So maybe it is not the creation of articles by bot that is a problem so much as creation by bot without a long term plan to work on the completed network of articles.
Birgitte SB
[1]http://biology.plosjournals.org/perlserv/?request=get-document&doi=10.13...
Birgitte SB wrote:
I think there was recently a thread about the press about the paper A Gene Wiki for Community Annotation of Gene Function [1]. I was reading it today and found it interesting in respect to views generally expressed on this mailing list against bot created articles. Personally I can't see why this sort of work described here should be required to be done by hand (as is the case where some wikipedias don't allow this sort of bot creation). Especially when analysis found that after the bot created stubs for all genes in the authorative database that were missing from Wikipedia, "approximately 50% of all edits to gene pages were made on the newly created pages."
PLoS Biology is a recognized journal for biology research, but not for wiki research. Their statements about the usefulness in wikis of bot-generated stubs are not backed up by verifiable evidence.
For example, they don't define what a "stub" is, and how the usefulness varies with that definition. The stub shown as example in the article (fig. 1) is far longer and more well-written than what one usually has to confront when criticizing stub articles in Wikipedia.
Their statistic that 50% of edits landed in new articles doesn't indicate quality or usefulness. It only says that carpet bombing might sometimes hit a target.
Their work is interesting biology. But for wiki research, this paper is merely of anecdotal interest. Maybe they are writing a separate article focused on wikis? Are the authors coming to Wikimania?
There is also interesting argument is made about how the existence of a complete network (even if, as in this case, partially consisting of bot-created stubs) leads to more efficient browing of the entire subject area.
Yes, if your task is to create a navigational user interface, then a wiki might be a useful tool. But that doesn't imply that this is a good method for creating a free encyclopedia.
--- On Mon, 7/14/08, Lars Aronsson lars@aronsson.se wrote:
From: Lars Aronsson lars@aronsson.se Subject: Re: [Foundation-l] Another look a bot creation of articles To: birgitte_sb@yahoo.com, "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Date: Monday, July 14, 2008, 4:53 PM Birgitte SB wrote:
I think there was recently a thread about the press
about the
paper A Gene Wiki for Community Annotation of Gene
Function [1].
I was reading it today and found it interesting in
respect to
views generally expressed on this mailing list against
bot
created articles. Personally I can't see why this
sort of work
described here should be required to be done by hand
(as is the
case where some wikipedias don't allow this sort
of bot
creation). Especially when analysis found that after
the bot
created stubs for all genes in the authorative
database that
were missing from Wikipedia, "approximately 50%
of all edits to
gene pages were made on the newly created pages."
PLoS Biology is a recognized journal for biology research, but not for wiki research. Their statements about the usefulness in wikis of bot-generated stubs are not backed up by verifiable evidence.
For example, they don't define what a "stub" is, and how the usefulness varies with that definition. The stub shown as example in the article (fig. 1) is far longer and more well-written than what one usually has to confront when criticizing stub articles in Wikipedia.
Their statistic that 50% of edits landed in new articles doesn't indicate quality or usefulness. It only says that carpet bombing might sometimes hit a target.
Their work is interesting biology. But for wiki research, this paper is merely of anecdotal interest. Maybe they are writing a separate article focused on wikis? Are the authors coming to Wikimania?
I saw the paper more as part of the effort to attract more subject experts to expand on the stubs than as the final evaluation of the project. Which really plays on what I hoped was a different angle towards the discussion of bot creation. The difference between if someone uses a bot to create stubs from an easily accessible database that they have no longterm interest in, or if an organized group uses a bot to create stubs as part of long-term project that includes contiuned involvement in the articles. Maybe you see no difference there, I don't know since you didn't respond to the conclusion of my email. I think various Wikipedias might be better served regulating the use of bot creation to well planned projects rather than outlawing bot creation. I think this example is a good "best practice" as far as bot creation goes. But most of all I think that every Wikipedia should make their own decision as to what to allow without giving much credit opinions that use hostile terms like "carpet-bombing" or otherwise frame the discussion as battleground between different Wikipedia communities (see previous threads on the subject).
Birgitte SB
2008/7/14 Birgitte SB birgitte_sb@yahoo.com:
I think there was recently a thread about the press about the paper A Gene Wiki for Community Annotation of Gene Function [1]. I was reading it today and found it interesting in respect to views generally expressed on this mailing list against bot created articles. Personally I can't see why this sort of work described here should be required to be done by hand (as is the case where some wikipedias don't allow this sort of bot creation). Especially when analysis found that after the bot created stubs for all genes in the authorative database that were missing from Wikipedia, "approximately 50% of all edits to gene pages were made on the newly created pages." There is also interesting argument is made about how the existence of a complete network (even if, as in this case, partially consisting of bot-created stubs) leads to more efficient browing of the entire subject area.
Obvioulsly not all bot creations are equal, but I wonder if the feelings so often expressed against bot creations have more to do with the manner of creating articles than abandoning them (drive-by creation). This project, run by subject experts who are tracking the additional editing to the created articles and courting more activity with papers like this one seem to be a different matter altogether. So maybe it is not the creation of articles by bot that is a problem so much as creation by bot without a long term plan to work on the completed network of articles.
Birgitte SB
[1]http://biology.plosjournals.org/perlserv/?request=get-document&doi=10.13...
I, for one, do not oppose bot article creation at all. There is great benefit to providing users with consistent, usable information on a complete set of topics. As long as the bot approval process ensures that bots are well examined before being started, there should be no problem. If there is a problem, we're a wiki and we can revert the edits.
wikimedia-l@lists.wikimedia.org