Process for a project to request a setting

[Ting Chen-2]

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
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Michael Bimmler]

On Mon, Jul 7, 2008 at 6:13 PM, Ting Chen <Wing.Philopp@...> 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

--
Michael Bimmler
mbimmler@...

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Kwan Ting Chan]

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@...> 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


_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Ting Chen-2]

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@...>
> An: Wikimedia Foundation Mailing List <foundation-l@...>
> 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@...> 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@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[VasilievVV]

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@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Gerard Meijssen-3]

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@...> 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@...
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[VasilievVV]

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

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Ting Chen-2]

> > 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].
>
> [1] http://www.mediawiki.org/wiki/Extension:Configure

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
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Birgitte SB]

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@...> wrote:

> From: Ting Chen <Wing.Philopp@...>
> Subject: Re: [Foundation-l] Process for a project to request a setting
> To: "Wikimedia Foundation Mailing List" <foundation-l@...>
> 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@...>
> > An: Wikimedia Foundation Mailing List
> <foundation-l@...>
> > 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@...> 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@...
> Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/foundation-l

     

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Bryan Tong Minh]

On Tue, Jul 8, 2008 at 2:22 PM, Ting Chen <Wing.Philopp@...> 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.

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Aryeh Gregor]

On Tue, Jul 8, 2008 at 2:19 AM, Ting Chen <Wing.Philopp@...> 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).

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Birgitte SB]

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.1371/journal.pbio.0060175&ct=1


     

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Lars Aronsson]

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.


--
  Lars Aronsson (lars@...)
  Aronsson Datateknik - http://aronsson.se

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Oldak Quill]

2008/7/14 Birgitte SB <birgitte_sb@...>:
> 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.1371/journal.pbio.0060175&ct=1


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.


--
Oldak Quill (oldakquill@...)

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Andrew Su]

As the author of the paper in question, I thought I'd chime in my two
cents here...

 

> 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.

 

Agreed, our intention was to create a resource for biologists, not to
make any broader statements about wikis as a whole.  Apologies if anyone
felt we were overinterpreting our observations, but I felt all of our
conclusions were supported by our analyses.  As for the statements not
being backed up by verifiable evidence, I (obviously) disagree.  All of
our figures and conclusions were derived from publicly-available sources
(edit histories, page sources, etc.), and anyone who is interested would
be able to reproduce our results.

 

> 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.

 

Perhaps there is some misunderstanding here in what the article said?
The 50% of edits refers to edits *subsequent* to our bot effort, not the
bot effort itself.  If there is still confusion, I'm happy to clarify in
more detail.

 

> 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?

 

Great, then we succeeded in our goal of doing interesting biology.  No,
we have no plans to attend Wikimania or do another article on "wiki
research", but that's mostly because it's not our field.  If anyone has
suggestions on how we might use our effort to comment on wiki research
and would like to collaborate, we're certainly open to hearing more.

 

... and in response to a comment on another thread, it is a bit
unfortunate that some headlines seem to indicate that this was a
foundation-sponsored activity.  But, alas, we don't write the
headlines...  (The title of the article we wrote is "A Gene Wiki for
Community Annotation of Gene Function".)

 

Regards,

Andrew

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

[Birgitte SB]

--- On Mon, 7/14/08, Lars Aronsson <lars@...> wrote:

> From: Lars Aronsson <lars@...>
> Subject: Re: [Foundation-l] Another look a bot creation of articles
> To: birgitte_sb@..., "Wikimedia Foundation Mailing List" <foundation-l@...>
> 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


     

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l