headers
Brian | 1 Jul 03:54
Picon
Favicon

Re: [Wikitech-l] On templates and programming languages

On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibber<brion@...> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Thomas Dalton | 1 Jul 04:46
Picon

Re: [Wikitech-l] On templates and programming languages

2009/7/1 Brian <Brian.Mingus@...>:
> 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@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Permalink | Reply | 0 comments |
headers
Robert Rohde | 1 Jul 05:16
Picon

Re: [Wikitech-l] On templates and programming languages

On Tue, Jun 30, 2009 at 6:54 PM, Brian<Brian.Mingus@...> wrote:
> On Tue, Jun 30, 2009 at 10:16 AM, Brion Vibber<brion@...> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian | 1 Jul 05:29
Picon
Favicon

Re: [Wikitech-l] On templates and programming languages

On Tue, Jun 30, 2009 at 9:16 PM, Robert Rohde<rarohde@...> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian | 1 Jul 07:16
Picon
Favicon

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?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Chad | 1 Jul 14:30
Picon

Re: How do you fully consult the community consensus?

I of course cannot speak for the Foundation. I only
write this in the view of a volunteer dev, like many
others.

That statement was written a long time ago when
Mediawiki was simply the software that runs Wikipedia.
It's now 2009, and Mediawiki is still the software that
runs Wikipedia. That being said, our outside user base
has grown massively in this time. A good number of our
bug reports and patches come from outside users, not
wikis within the WMF.

That's all fine and dandy, but our number one goal is
still (admittedly or not) to keep developing for Wikipedia.
I of course support full consultation with the wikis when
it is beneficial to do so. Simple bugfixes or enhancements
don't need massive pre-announcement and input. It
slows down the development lifecycle for everyone.
Most devs don't want to be involved in massive enwiki
debates over where to put a link: we just want your
final consensus on what you want done (and that itself
can be very time consuming). Larger impact things (like
the retooling of wikitext) definitely need wider input
than just wikitech-l. I believe that the WMF
community and wider wiki community should be
solicited for such wide-sweeping changes. Tangentally,
I think we all as a wiki community need to standardize
"What is wikitext" in a formal way, but that's another
discussion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Gray | 1 Jul 14:43
Picon

Re: [Wikitech-l] On templates and programming languages

2009/7/1 Robert Rohde <rarohde@...>:

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

This is a marvellous idea, and presumably a lot of the code for it is
already in existence (what with <ref> etc). It'd also solve the issue
with people wanting to "templatise" content such as infoboxes in order
to reduce the clutter on a specific page.

Can anyone see any obvious downsides?

--

-- 
- Andrew Gray
  andrew.gray@...

_______________________________________________
foundation-l mailing list
foundation-l@...
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Permalink | Reply | 0 comments |
headers
Gerard Meijssen | 1 Jul 16:01
Picon

Re: How do you fully consult the community consensus?

Hoi,
The answer seems obvious: "in the same way it has always been done". There
are a few things that are quite obvious, the community will not be asked
when things need to be changed because they are broken. There have been
indications that the template stuff has been broken and as it is now clear
that it is can and does break the system and it will be changed. There is a
discussion going on on the Wikitech list and that is where the community can
be found that has a clue.

When you consider MediaWiki, it is used in many languages and for many
projects. Some basic functionality is just not good enough. I am grateful
for the Usability Initiative but for many languages the issues it addresses
are already too sophisticated.  You may remember my rants about Lingala..
They do not have a community because we do not even fully support the Latin
script. At last weeks Open Translation Tools conference I met Dwayne Bailey
the leading light on internationalisation and localisation for African
languages and he is willing to help us make MediaWiki ready for African
languages.

MediaWiki is open source software. This means that you pay for what what is
not there. You can pay by suffering and you can pay by developing software.
When you think you know what the community needs, you can do your utmost to
make it happen. I have been active in the development of software and I
consider the LocalisationUpdate extension extremely relevant for the
community that does not rely on the English language.

All in all, the community is only dependent on the Foundation for the
assessment of code. When functionality is Brion proof, you may find that the
community sets the agenda.
Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 1 Jul 20:50
Picon

Re: How do you fully consult the community consensus?

On Wed, Jul 1, 2009 at 1:16 AM, Brian wrote: > 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? Yes, IMO (as a
volunteer dev). If something is expected to be controversial on
non-technical grounds, there's normally a per-community decision, like with
FlaggedRevs or whatnot. The overwhelming majority of technical work
comprises straightforward enhancements and bug fixes that only really
deserves technical attention. Users who are interested can sign up to
wikitech-l and hang out in #mediawiki. Those who aren't can just use the
software. > Or is this just a guideline that has been on Jimbo's user page
for many > years which is not really relevant Yes. > How large of a change
to the software requires full consultation? It's not about large, it's about
the effect it has on users. There are enormous overhauls like the new video
upload system that don't need to be discussed with the community at all,
because everyone agrees that they're wanted. On the other hand, there are
plenty of one-line changes that would require community consensus (like,
say, giving all users rollback by default). > After consulting the
community, does the Foundation feel it is within its > power to then choose
something different? I can't speak for Wikimedia, but I don't see how it
could possibly be considered outside the Foundation's power to ignore the
community. It owns the site. It can and does overrule individual communities
sometimes, in technical matters and non-technical alike. For instance, it
imposes its copyright policies regardless of community consensus (and some
communities don't like those policies at all). An upcoming technical change
that will probably be very controversial is deployment of the Vector skin by
default -- I predict a lot of people will complain about lack of consensus
and be very politely told "too bad, we know better because we just spent a
million dollars on a usability study". > Does the Foundation take the
requirement that all changes to the software > must be gradual and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Moeller | 2 Jul 03:30
Picon
Gravatar

$300K grant for Wikimedia Commons

All,

I'm very happy to announce that the Ford Foundation has awarded a
$300,000 grant to the Wikimedia Foundation to improve our interfaces
and workflows for multimedia uploading. Press release here:

http://wikimediafoundation.org/wiki/Press_releases/Wikimedia_Ford_Foundation_Grant_July_2009

For the first time we're also sharing a full grant proposal, with
permission of the Ford Foundation. You can find it here:

http://upload.wikimedia.org/wikipedia/foundation/f/f9/WMF_Ford_Multimedia_Participation_Project.pdf

It should give you a good idea about what we can do within the scope
of this project. As a brief recap, Michael Dale has already done some
good work on external repository searches and transfers, and
integration of uploading into the editing UI, so we're hoping to build
on top of this to really get the workflow for
licensing/upload/review/embedding of media files nailed.

We've also been having initial discussions with some of the Wikimedia
chapters about possible models for working together on the execution
of this. For example, we want to make sure that we can facilitate
fruitful face-to-face meetings with Commons practitioners, and there
is plenty of technical work to be done that can be decentralized and
shared. Exciting projects like Wikimedia Germany's investment in
multilingual search are already underway, so hopefully over the next
year, we'll see lots of useful activity culminating in genuine
improvements for Commons and beyond.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane