Re: [Foundation-l] antisocial production pt:wiki policies
Virgilio A. P. Machado wrote: Marc, you comment is not very optimistic, but it was a great incentive to do what I announced above. Hopefully others will be more encouraged to voice their ideas about other matters, knowing they'll find a friendly hear and some useful and very welcome feedback. Marc and I just happen to come from a generation of grumpy old men who have never had enough good sense to abandon our principles. If you do that long enough the optimism can suffer until you can pull yourself off the carpet and try again. I'm glad to find Nathan in a better mood this time :-). Of course language is a problem. This is indeed a very interesting problem that I hope has a solution in the international wikipedian community. That is also an obstacle to getting on greater detail in this list since most of its members would not be able to verify and cross check that information. The Foundation can't afford to let a Wikipedia on some obscure language (that is not the case of Portuguese) to run wild and be run by some mob. At some time a flag will go up. What then? I could offer some suggestions, but I was hoping that you all would come up with some useful and tested procedures. It's unrealistic to expect those who do not speak your language to solve the problems. Just because the anglophones happen to be hanging from the top of the Tower of Babel does not imply that they have any greater expertise. I am willing to concede that the behaviour on some obscure language projects is nothing short of outrageous. How do you determine what the Foundation can or can't afford? Being able to deal with the problems requires for the community to have a critical membership mass. The Foundation can't demand other solutions without compromising NPOV and individual responsibility. If there are specific problems in a project, and nobody knows about them, nothing can be done. I'm afraid to have to admit that the lack of interest and advice that I got, so far, covers both list and off-list. I wish that would change, again not only for the present case, but what kind of message is this sending to others? How sure can we all be that there aren't or there would not be other cases in the future? The lack of interest is no surprise. Why would anyone with an already full plate of problems want to take on a new one? You can never be sure that there will be no other cases in the future. Quite frankly, I would rather be wrong (not a very palatable prospect) but give others the assurance that their voices will be heard, than letting them remember the story of this guy from somewhere who blew the whistle and nobody cared. Preferring to be wrong is very altruistic in an environment where most are desperate to be right, and to win. You don't have to worry about them remembering that nobody cared when they never acknowledge that someone was blowing the whistle in the first place. Ec ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Wikipedia article traffic statistics - copyright?
K. Peachey wrote: They might not be, but with that San Francisco bus data issue [1] happening at the moment, everyone's checking everything these days to cover their asses. [1]. The Battle Over Who Owns Bus Arrival Times: http://www.techdirt.com/articles/20090628/1419595382.shtml So why should a local squabble cause such a paranoid panic? Ec ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] Wikipedia article traffic statistics - copyright?
On Tue, Jun 30, 2009 at 09:01, Ray Saintongesainto...@telus.net wrote: [1]. The Battle Over Who Owns Bus Arrival Times: So why should a local squabble cause such a paranoid panic? Cos they're living in the United States of Litigations? ;-) g ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] antisocial production pt:wiki policies
Behavior on many projects IS outrageous; when someone complains the response is almost universally that the foundation doesn't get involved in local project business. Mark skype: node.ue On Mon, Jun 29, 2009 at 11:44 PM, Ray Saintongesainto...@telus.net wrote: Virgilio A. P. Machado wrote: Marc, you comment is not very optimistic, but it was a great incentive to do what I announced above. Hopefully others will be more encouraged to voice their ideas about other matters, knowing they'll find a friendly hear and some useful and very welcome feedback. Marc and I just happen to come from a generation of grumpy old men who have never had enough good sense to abandon our principles. If you do that long enough the optimism can suffer until you can pull yourself off the carpet and try again. I'm glad to find Nathan in a better mood this time :-). Of course language is a problem. This is indeed a very interesting problem that I hope has a solution in the international wikipedian community. That is also an obstacle to getting on greater detail in this list since most of its members would not be able to verify and cross check that information. The Foundation can't afford to let a Wikipedia on some obscure language (that is not the case of Portuguese) to run wild and be run by some mob. At some time a flag will go up. What then? I could offer some suggestions, but I was hoping that you all would come up with some useful and tested procedures. It's unrealistic to expect those who do not speak your language to solve the problems. Just because the anglophones happen to be hanging from the top of the Tower of Babel does not imply that they have any greater expertise. I am willing to concede that the behaviour on some obscure language projects is nothing short of outrageous. How do you determine what the Foundation can or can't afford? Being able to deal with the problems requires for the community to have a critical membership mass. The Foundation can't demand other solutions without compromising NPOV and individual responsibility. If there are specific problems in a project, and nobody knows about them, nothing can be done. I'm afraid to have to admit that the lack of interest and advice that I got, so far, covers both list and off-list. I wish that would change, again not only for the present case, but what kind of message is this sending to others? How sure can we all be that there aren't or there would not be other cases in the future? The lack of interest is no surprise. Why would anyone with an already full plate of problems want to take on a new one? You can never be sure that there will be no other cases in the future. Quite frankly, I would rather be wrong (not a very palatable prospect) but give others the assurance that their voices will be heard, than letting them remember the story of this guy from somewhere who blew the whistle and nobody cared. Preferring to be wrong is very altruistic in an environment where most are desperate to be right, and to win. You don't have to worry about them remembering that nobody cared when they never acknowledge that someone was blowing the whistle in the first place. Ec ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] [Wikitech-l] On templates and programming languages
On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibberbr...@wikimedia.org wrote:
As many folks have noted, our current templating system works ok for
simple things, but doesn't scale well -- even moderately complex
conditionals or text-munging will quickly turn your template source into
what appears to be line noise.
In addition to changing the programming language that is used in the
template namespace a lot of progress can be made on the readability of
articles (and thus how usable they are) by rethinking how we invoke
templates, or rather how we make data available to templates.
If you look at the George W. Bush article you see that the first 50
lines of the article are template code and that his birthday is
declared multiple times like so:
|birth_date={{birth date and age|mf=yes|1946|7|6}}
born July 6, 1946
|DATE OF BIRTH=July 6, 1946
Editors clearly need a better system for declaring facts about
articles and then using them in advanced template programming. One can
imagine an alternate system where his birthday is only declared once,
like so, in the article text: born on [[birthday::July 6, 1946]]. And
so on for all the other facts listed in his infobox. Rather than
declaring them explicitly in the infobox, you declare them explicitly
inline in the text in a highly readable format.
Then there is the issue of calling templates. Where do you place them
within the article? Much like MediaWiki itself I suggest we introduce
the notion of hooks. Beginning of article, end of article. Beginning
of section, end of section. Beginning of paragraph end of paragraph.
Template programmers can use these hooks to inject data that is
declared explicitly in the article into various points of the article.
This can be thought of as a separation of content and presentation.
Articles have the constraint that their source code must, under all
circumstances, be highly readable to our visitors. That way our
visitors might become encyclopedia writers! Associated with those
articles is another page where users can control higher level
organizations of the content in the body of text. They can format it
in infobox style, process it any way they like using our new
programming language, and place it in a variety of locations
throughout the article without sacrificing the readability of the
wikitext at all.
It will take a little bit more conceptual work to handle all cases,
such as inline references, etc.., etc... But the bottom line is that
the source code to articles on Wikipedia has become so complicated
that it is now too difficult for reasonable people to consider
editing. One user said that adding a new programming language to
MediaWiki is totally orthogonal to the method that we use to pass data
to those programs, or the context in which those programs are called.
I couldn't disagree more - one of the major reasons Wikipedia is so
unreadable today is because of the way we call templates from
articles. From the bottom of the design to the top, it needs to be
rethought. I believe that this conversation should be held far beyond
wikitech-l and should be made available to subscribers of almost all
of our lists and also the large pool of contributors. One of the
reasons that we ended up with ParserFunctions is that very few people
were involved in the conversation. Do we even understand the problem
that needs to be solved? I am not convinced that it has been
adequately characterized.
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] [Wikitech-l] On templates and programming languages
2009/7/1 Brian brian.min...@colorado.edu: Editors clearly need a better system for declaring facts about articles and then using them in advanced template programming. One can imagine an alternate system where his birthday is only declared once, like so, in the article text: born on [[birthday::July 6, 1946]]. And so on for all the other facts listed in his infobox. Rather than declaring them explicitly in the infobox, you declare them explicitly inline in the text in a highly readable format. That's the idea behind Semantic MediaWiki. What are the chances of getting that implemented on the Wikimedia wikis? (That's a very different discussion to the one we're having here, though.) ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] [Wikitech-l] On templates and programming languages
On Tue, Jun 30, 2009 at 6:54 PM, Brianbrian.min...@colorado.edu wrote:
On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibberbr...@wikimedia.org wrote:
As many folks have noted, our current templating system works ok for
simple things, but doesn't scale well -- even moderately complex
conditionals or text-munging will quickly turn your template source into
what appears to be line noise.
In addition to changing the programming language that is used in the
template namespace a lot of progress can be made on the readability of
articles (and thus how usable they are) by rethinking how we invoke
templates, or rather how we make data available to templates.
If you look at the George W. Bush article you see that the first 50
lines of the article are template code and that his birthday is
declared multiple times like so:
|birth_date={{birth date and age|mf=yes|1946|7|6}}
born July 6, 1946
|DATE OF BIRTH=July 6, 1946
Editors clearly need a better system for declaring facts about
articles and then using them in advanced template programming. One can
imagine an alternate system where his birthday is only declared once,
like so, in the article text: born on [[birthday::July 6, 1946]]. And
so on for all the other facts listed in his infobox. Rather than
declaring them explicitly in the infobox, you declare them explicitly
inline in the text in a highly readable format.
Then there is the issue of calling templates. Where do you place them
within the article? Much like MediaWiki itself I suggest we introduce
the notion of hooks. Beginning of article, end of article. Beginning
of section, end of section. Beginning of paragraph end of paragraph.
Template programmers can use these hooks to inject data that is
declared explicitly in the article into various points of the article.
This can be thought of as a separation of content and presentation.
Articles have the constraint that their source code must, under all
circumstances, be highly readable to our visitors. That way our
visitors might become encyclopedia writers! Associated with those
articles is another page where users can control higher level
organizations of the content in the body of text. They can format it
in infobox style, process it any way they like using our new
programming language, and place it in a variety of locations
throughout the article without sacrificing the readability of the
wikitext at all.
It will take a little bit more conceptual work to handle all cases,
such as inline references, etc.., etc... But the bottom line is that
the source code to articles on Wikipedia has become so complicated
that it is now too difficult for reasonable people to consider
editing. One user said that adding a new programming language to
MediaWiki is totally orthogonal to the method that we use to pass data
to those programs, or the context in which those programs are called.
I couldn't disagree more - one of the major reasons Wikipedia is so
unreadable today is because of the way we call templates from
articles. From the bottom of the design to the top, it needs to be
rethought. I believe that this conversation should be held far beyond
wikitech-l and should be made available to subscribers of almost all
of our lists and also the large pool of contributors. One of the
reasons that we ended up with ParserFunctions is that very few people
were involved in the conversation. Do we even understand the problem
that needs to be solved? I am not convinced that it has been
adequately characterized.
I'm not sure how one would make your hook system work in a way that
was practical and not totally opaque to the editor.
An idea that has been toyed with a couple of other places is to allow
defined blocks and references to them in article text. For example:
An article might start:
display name=infobox /
Thomas Jefferson was the third president...
and at the end of the article have:
define name=infobox
{{infobox
...
}}
/define
It would provide the flexibility to place items where needed in the
article while moving the complex wikicode into a separate segment
that's less likely to confuse novices. One could also call display
multiple times if there is an element (like a birth date) that needs
to be repeated in some awkward manner.
There is actually code lying around somewhere that implements such a
system for ref so that the first call would not need to attach the
full reference definition but could simply use ref name=foo / if a
corresponding ref_define name=foo.../ref appeared later in the
text.
Personally, my guess is that a system of placement by reference would
make for a more flexible / less confusing approach than trying to
create a system of article hooks and attach infoboxes and the like to
them.
-Robert Rohde
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: [Foundation-l] [Wikitech-l] On templates and programming languages
On Tue, Jun 30, 2009 at 9:16 PM, Robert Rohderaro...@gmail.com wrote:
I'm not sure how one would make your hook system work in a way that
was practical and not totally opaque to the editor.
An idea that has been toyed with a couple of other places is to allow
defined blocks and references to them in article text. For example:
An article might start:
display name=infobox /
Thomas Jefferson was the third president...
and at the end of the article have:
define name=infobox
{{infobox
...
}}
/define
It would provide the flexibility to place items where needed in the
article while moving the complex wikicode into a separate segment
that's less likely to confuse novices. One could also call display
multiple times if there is an element (like a birth date) that needs
to be repeated in some awkward manner.
There is actually code lying around somewhere that implements such a
system for ref so that the first call would not need to attach the
full reference definition but could simply use ref name=foo / if a
corresponding ref_define name=foo.../ref appeared later in the
text.
Personally, my guess is that a system of placement by reference would
make for a more flexible / less confusing approach than trying to
create a system of article hooks and attach infoboxes and the like to
them.
Placement by reference aka move all the nasty stuff to the bottom :p
I think this approach would be good combined with the ability to
declare facts ala `born on [[birthday::July 6, 1946]]'. That way we no
longer have nasty stuff at all - we simply reference a template such
as display name=infobox / which gets its arguments from the facts
declared in the article which called it.
The method of declaring facts in wikilinks is indeed derived from
semantic mediawiki. But I just look at it as a testbed for good ideas,
not as an extension for WMF to install.
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
[Foundation-l] How do you fully consult the community consensus?
Going forward, how does the Foundation plan to make large changes to the software in full consultation with the community consensus? Is the assumption that all of the members of the community who are knowledgeable and interested have already signed up to the relevant mailing lists and all that is needed is to send out a quick 'ping' and get their thoughts? What constitutes the community when it comes to the software? Or is this just a guideline that has been on Jimbo's user page for many years which is not really relevant since laymen should not really be involved in technical decisions? Is there anyone at the Foundation who currently takes this principle seriously? Honestly? What about the developers - are they aware of and actively engaged in implementing this principle? Does the Foundation feel that it doesn't actually need to consult the community? It can determine the technically best solution for the projects and then implement it without soliciting feedback from as many people as possible? What would constitute due diligence in contacting the community? For example, suppose that the Foundation had determined that there were 5 really good solutions to a problem in the software and that they take full consultation seriously. Could you then present those 5 solutions to the community en masse using a survey, analyze the results and choose a winner (or have a runoff?). How large of a change to the software requires full consultation? After consulting the community, does the Foundation feel it is within its power to then choose something different? Does the Foundation take the requirement that all changes to the software must be gradual and reversible seriously, or not? What does that mean to you? Thanks, Brian ___ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
