Message: 1 Date: Thu, 2 Jul 2009 16:09:00 +0100 From: Thomas Dalton thomas.dalton@gmail.com Subject: Re: [Foundation-l] Fwd: How do you fully consult the community consensus? To: Wikimedia Foundation Mailing List foundation-l@lists.wikimedia.org Message-ID: a4359dff0907020809g4cb248h2095752d36c6d267@mail.gmail.com Content-Type: text/plain; charset=UTF-8
2009/7/2 Brian Brian.Mingus@colorado.edu:
As the projects have grown and as they have become more centrally managed in a top down fashion it has become increasingly difficult for ideas to percolate from the bottom up.
I'm curious. In your perspective who is doing the central management that makes it difficult for ideas to percolate up? WMF, Jimmy, Board, select administrators/highly involved community members? In your opinion, is there an infrastructure barrier or a personalities one?
jriggs
On Thu, Jul 2, 2009 at 6:59 PM, Jennifer Riggs jriggs@wikimedia.org wrote:
I'm curious. In your perspective who is doing the central management that makes it difficult for ideas to percolate up? WMF, Jimmy, Board, select administrators/highly involved community members? In your opinion, is there an infrastructure barrier or a personalities one?
jriggs
It's an infrastructure, policy and outreach issue. I assume that every single person has the very best for the projects in mind and is doing it for the right reasons.
That said, I see the definition of community being interpreted very narrowly. I liked what I saw with AbuseFilter but that was a singular case. Filtering edits is almost on the same level as showing advertisements. In these rare cases any change you try to make will quickly make its way through the community because many people will be outraged. There are a lot of other situations that don't propagate as well, not because they aren't very important, but because people just don't know about them.
I really like the ParserFunctions example. Enabled with hardly any discussion and now used 500,000 times on the English Wikipedia. It had a major effect on Wikipedia that made it much harder to use. And now we are stuck in a programming mindset and we all assume that we all agreed to come here. It just isn't the case. You won't be able to find where that agreement happened.
Sorry, where I said AbuseFilter I meant to say FlaggedRevisions. I'm not sure on how AbuseFilter came to be agreed on.
On Thu, Jul 2, 2009 at 7:15 PM, Brian Brian.Mingus@colorado.edu wrote:
On Thu, Jul 2, 2009 at 6:59 PM, Jennifer Riggs jriggs@wikimedia.orgwrote:
I'm curious. In your perspective who is doing the central management that makes it difficult for ideas to percolate up? WMF, Jimmy, Board, select administrators/highly involved community members? In your opinion, is there an infrastructure barrier or a personalities one?
jriggs
It's an infrastructure, policy and outreach issue. I assume that every single person has the very best for the projects in mind and is doing it for the right reasons.
That said, I see the definition of community being interpreted very narrowly. I liked what I saw with AbuseFilter but that was a singular case. Filtering edits is almost on the same level as showing advertisements. In these rare cases any change you try to make will quickly make its way through the community because many people will be outraged. There are a lot of other situations that don't propagate as well, not because they aren't very important, but because people just don't know about them.
I really like the ParserFunctions example. Enabled with hardly any discussion and now used 500,000 times on the English Wikipedia. It had a major effect on Wikipedia that made it much harder to use. And now we are stuck in a programming mindset and we all assume that we all agreed to come here. It just isn't the case. You won't be able to find where that agreement happened.
On Thu, Jul 2, 2009 at 9:19 PM, Brian Brian.Mingus@colorado.edu wrote:
Sorry, where I said AbuseFilter I meant to say FlaggedRevisions. I'm not sure on how AbuseFilter came to be agreed on.
On Thu, Jul 2, 2009 at 7:15 PM, Brian Brian.Mingus@colorado.edu wrote:
On Thu, Jul 2, 2009 at 6:59 PM, Jennifer Riggs <jriggs@wikimedia.org wrote:
I'm curious. In your perspective who is doing the central management that makes it difficult for ideas to percolate up? WMF, Jimmy, Board, select administrators/highly involved community members? In your opinion, is there an infrastructure barrier or a personalities one?
jriggs
It's an infrastructure, policy and outreach issue. I assume that every single person has the very best for the projects in mind and is doing it
for
the right reasons.
That said, I see the definition of community being interpreted very narrowly. I liked what I saw with AbuseFilter but that was a singular
case.
Filtering edits is almost on the same level as showing advertisements. In these rare cases any change you try to make will quickly make its way through the community because many people will be outraged. There are a
lot
of other situations that don't propagate as well, not because they aren't very important, but because people just don't know about them.
I really like the ParserFunctions example. Enabled with hardly any discussion and now used 500,000 times on the English Wikipedia. It had a major effect on Wikipedia that made it much harder to use. And now we are stuck in a programming mindset and we all assume that we all agreed to
come
here. It just isn't the case. You won't be able to find where that
agreement
happened.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On which wiki do you mean, for FlaggedRevs? For the English Wikipedia, my understanding is that consensus was reached in favor of a limited trial for FlaggedRevs three months ago, but it hasn't been enabled yet because the tech team is still tidying things up and checking that everything works < http://lists.wikimedia.org/pipermail/wikitech-l/2009-May/043187.html%3E. This was not a matter of the Foundation consulting the community—the community petitioned the Foundation, from what I can tell.
I realize that 324 people voting might not qualify as "the community" for you, but this is the way changes get made on the English Wikipedia: people debate for a while (an extremely long while, as the case may be), proposals get tossed around, and eventually consensus forms among the portion of editors that is active in policy discussions. This system is not ideal, but it's the system that's in place. If you want to call the validity of the English Wikipedia's decision-making processes into question, then do so, but I don't think you should frame the discussion as being about the Foundation or software changes.
On Fri, Jul 3, 2009 at 1:00 AM, Benjamin Lees emufarmers@gmail.com wrote:
On Thu, Jul 2, 2009 at 9:19 PM, Brian Brian.Mingus@colorado.edu wrote:
Sorry, where I said AbuseFilter I meant to say FlaggedRevisions. I'm not sure on how AbuseFilter came to be agreed on.
On Thu, Jul 2, 2009 at 7:15 PM, Brian Brian.Mingus@colorado.edu wrote:
On Thu, Jul 2, 2009 at 6:59 PM, Jennifer Riggs <jriggs@wikimedia.org wrote:
I'm curious. In your perspective who is doing the central management that makes it difficult for ideas to percolate up? WMF, Jimmy, Board, select administrators/highly involved community members? In your opinion, is there an infrastructure barrier or a personalities one?
jriggs
It's an infrastructure, policy and outreach issue. I assume that every single person has the very best for the projects in mind and is doing
it
for
the right reasons.
That said, I see the definition of community being interpreted very narrowly. I liked what I saw with AbuseFilter but that was a singular
case.
Filtering edits is almost on the same level as showing advertisements.
In
these rare cases any change you try to make will quickly make its way through the community because many people will be outraged. There are a
lot
of other situations that don't propagate as well, not because they
aren't
very important, but because people just don't know about them.
I really like the ParserFunctions example. Enabled with hardly any discussion and now used 500,000 times on the English Wikipedia. It had
a
major effect on Wikipedia that made it much harder to use. And now we
are
stuck in a programming mindset and we all assume that we all agreed to
come
here. It just isn't the case. You won't be able to find where that
agreement
happened.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On which wiki do you mean, for FlaggedRevs? For the English Wikipedia, my understanding is that consensus was reached in favor of a limited trial for FlaggedRevs three months ago, but it hasn't been enabled yet because the tech team is still tidying things up and checking that everything works < http://lists.wikimedia.org/pipermail/wikitech-l/2009-May/043187.html%3E. This was not a matter of the Foundation consulting the community—the community petitioned the Foundation, from what I can tell.
i didn't know it happened that way. I thought that, quite some time ago, the Foundation paid a developer 20k to develop the extension, and then got community approval for at trial?
On Fri, Jul 3, 2009 at 8:08 AM, Brian Brian.Mingus@colorado.edu wrote:
On Fri, Jul 3, 2009 at 1:00 AM, Benjamin Lees emufarmers@gmail.comwrote:
On which wiki do you mean, for FlaggedRevs? For the English Wikipedia, my understanding is that consensus was reached in favor of a limited trial for FlaggedRevs three months ago, but it hasn't been enabled yet because the tech team is still tidying things up and checking that everything works < http://lists.wikimedia.org/pipermail/wikitech-l/2009-May/043187.html%3E. This was not a matter of the Foundation consulting the community—the community petitioned the Foundation, from what I can tell.
i didn't know it happened that way. I thought that, quite some time ago, the Foundation paid a developer 20k to develop the extension, and then got community approval for at trial?
Oh nevermind, I must be thinking of the ratings extension?
On Thu, Jul 2, 2009 at 6:15 PM, BrianBrian.Mingus@colorado.edu wrote: <snip>
I really like the ParserFunctions example. Enabled with hardly any discussion and now used 500,000 times on the English Wikipedia. It had a major effect on Wikipedia that made it much harder to use. And now we are stuck in a programming mindset and we all assume that we all agreed to come here. It just isn't the case. You won't be able to find where that agreement happened.
The initial parser functions were a replacement for {{qif}} and kin. The enwiki community had already adopted a significant degree of programming in template space. But they did so in a half-assed way that was bad for server load and template management, so bad in fact that their approach was provoking arguments between the community and the developers (see the enwiki history of WT:AUM circa 2006, for example). The initial parser functions where created to answer that demand in the community in a way that wouldn't cause the servers to explode.
Hence the demand for programmatic templates came from the community initially, the developers simply responded to that in a way that was necessary to keep things working. (For the record, I'm referring to the earliest history of ParserFunctions. I'm not sure about the history of #expr and some of the later bits.)
-Robert Rohde
On Thu, Jul 2, 2009 at 8:06 PM, Robert Rohde rarohde@gmail.com wrote:
On Thu, Jul 2, 2009 at 6:15 PM, BrianBrian.Mingus@colorado.edu wrote:
<snip> > I really like the ParserFunctions example. Enabled with hardly any > discussion and now used 500,000 times on the English Wikipedia. It had a > major effect on Wikipedia that made it much harder to use. And now we are > stuck in a programming mindset and we all assume that we all agreed to come > here. It just isn't the case. You won't be able to find where that agreement > happened.
The initial parser functions were a replacement for {{qif}} and kin. The enwiki community had already adopted a significant degree of programming in template space.
The developer that abused templates so that qif could be written does not constitute a consensus. The conversations regarding programming on Wikipedia were extremely limited given their impact.
On Thu, Jul 2, 2009 at 10:11 PM, BrianBrian.Mingus@colorado.edu wrote:
On Thu, Jul 2, 2009 at 8:06 PM, Robert Rohde rarohde@gmail.com wrote:
On Thu, Jul 2, 2009 at 6:15 PM, BrianBrian.Mingus@colorado.edu wrote:
<snip> > I really like the ParserFunctions example. Enabled with hardly any > discussion and now used 500,000 times on the English Wikipedia. It had a > major effect on Wikipedia that made it much harder to use. And now we are > stuck in a programming mindset and we all assume that we all agreed to come > here. It just isn't the case. You won't be able to find where that agreement > happened.
The initial parser functions were a replacement for {{qif}} and kin. The enwiki community had already adopted a significant degree of programming in template space.
The developer that abused templates so that qif could be written does not constitute a consensus. The conversations regarding programming on Wikipedia were extremely limited given their impact. _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Of course you're not going to see massive community-wide discussions on the intricacies of wikitext and template programming. Most people don't care enough, as long as it works.
{{qif}} was being used massively, even if the majority of the community didn't know about it (or care). It supported their work and allowed them to do the things with templates that they needed in articles. I would argue these complex templates came from the community's needs.
ParserFunctions then came along because {{qif}} sucked.
-Chad
2009/7/3 Chad innocentkiller@gmail.com:
{{qif}} was being used massively, even if the majority of the community didn't know about it (or care). It supported their work and allowed them to do the things with templates that they needed in articles. I would argue these complex templates came from the community's needs.
Your last sentence is key here. Templates that present a (relatively) simple interface but have complex plumbing to do cool things are much-wanted and much-needed.
However, the ParserFunctions language sucks because it was made up as it goes along and resembles nothing so much as an [[esoteric programming language]]. A better language will make it easier to program templates that do complex things with a simple interface.
- d.
2009/7/6 David Gerard dgerard@gmail.com:
2009/7/3 Chad innocentkiller@gmail.com:
{{qif}} was being used massively, even if the majority of the community didn't know about it (or care). It supported their work and allowed them to do the things with templates that they needed in articles. I would argue these complex templates came from the community's needs.
Your last sentence is key here. Templates that present a (relatively) simple interface but have complex plumbing to do cool things are much-wanted and much-needed.
However, the ParserFunctions language sucks because it was made up as it goes along and resembles nothing so much as an [[esoteric programming language]]. A better language will make it easier to program templates that do complex things with a simple interface.
Questionable. Since for fairly obvious reasons you can't let wikipedians execute arbitrary code through templates there is always going to be the problem of wikipedians useing workarounds that generate problematical code.
2009/7/6 geni geniice@gmail.com:
Questionable. Since for fairly obvious reasons you can't let wikipedians execute arbitrary code through templates there is always going to be the problem of wikipedians useing workarounds that generate problematical code.
ParserFunctions is already Turing-complete, so your first clause is factually inaccurate. The present workaround is to kill template computations that take too long. The problems are: (1) they're hard to program (2) they're hard to parse.
- d.
2009/7/6 David Gerard dgerard@gmail.com:
2009/7/6 geni geniice@gmail.com:
Questionable. Since for fairly obvious reasons you can't let wikipedians execute arbitrary code through templates there is always going to be the problem of wikipedians useing workarounds that generate problematical code.
ParserFunctions is already Turing-complete, so your first clause is factually inaccurate. The present workaround is to kill template computations that take too long. The problems are: (1) they're hard to program (2) they're hard to parse.
I know this. Take too long though isn't an option because you would hit issues with templates that only run some of the time. Current limits on templates are rather more complex. I would argue that arbitrary code by definition includes code with far more steps than than ParserFunctions allows.
Getting back to the point attempts to highly optimize code to stay within whatever the new equivalent of [[Wikipedia:Template_limits]] would risk even a fairly clean language turning into something of a mess.
On Mon, Jul 6, 2009 at 10:29 AM, genigeniice@gmail.com wrote: <snip>
Getting back to the point attempts to highly optimize code to stay within whatever the new equivalent of [[Wikipedia:Template_limits]] would risk even a fairly clean language turning into something of a mess.
Any reasonable attempt at a clean language should reduce the coding complexity in the most common use cases compared to the current system. Yes, there will always be boundary cases that are likely to be complicated and hackish; however, I'd consider it a net benefit as long as the most common cases are made more legible and intelligible.
-Robert Rohde
On Thu, Jul 2, 2009 at 10:06 PM, Robert Rohderarohde@gmail.com wrote:
(For the record, I'm referring to the earliest history of ParserFunctions. I'm not sure about the history of #expr and some of the later bits.)
#expr was present since the first commit (r13505).
wikimedia-l@lists.wikimedia.org