Re: [Wikimedia-l] Women in red

[pi zero]

Based on my own experience on en.wn, I believe copyright/plagiary detection
cannot be fully automated without introducing horrific errors, for the same
reason translation can't be:  doing the task properly requires knowing what
the text means.

On Sun, Oct 15, 2017 at 10:47 AM, James Heilman  wrote:

> Correction:
>
> There is a tool that automatically checks for copyright infringement.
> It is called CopyPatrol
>
> https://tools.wmflabs.org/copypatrol/en
>
> James
>
> On Sun, Oct 15, 2017 at 8:02 AM, Gnangarra  wrote:
> > I cant believe this
> > https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_
> in_Red/The_World_Contest
> > has
> > got WMF funding, the idea of trying to create 100,000 stub articles on
> > english wikipedia without any thought to how it'll impact on the
> > community.
> >
> > I find it ironic that a competition is being funded to encourage current
> > contributors to do what we wont accept from new editors.  If a new editor
> > was to create an article it wouldnt pass through the Articles for
> Creation
> > process because its half the size of the minimum set there. Many of the
> > competition articles will just get tagged CSD - A1, A7, A9 even G2
> >
> > While there is a nice bot that will count the size of the prose, there is
> > no automated process for checking copyright violations, checking for
> > notability and most importantly checking for BLP with the aim of 100,000
> > the community will years to clean up the mess that is about to be
> created.
> >
> > we are 15 days from this disaster commencing
> >
> > --
> > G
> > nangarra
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] "News Integrity Initiative" at CUNY

[pi zero]

Nupedia had severely defective strategy and tactics.  It was also an
encyclopedia, not a news project. So it has pretty much zero bearing on any
aspect of the current situation.

On Mon, Apr 10, 2017 at 1:11 PM, Gerard Meijssen <gerard.meijs...@gmail.com>
wrote:

> Hoi,
> Vetting before publication proved a failure. It is why we have Wikipedia
> and not Nupedia.
> Thanks,
>  GerardM
>
> On 10 April 2017 at 14:44, pi zero <wn.pi.z...@gmail.com> wrote:
>
> > English Wikinews took serious measures for reliability back in 2009.  For
> > our pains, we've received mostly grief from the Foundation, and from a
> > vocal segment of the Wikipedian community.  If they consulted, before
> this
> > expertise-lending, with the sister project that specializes in
> > vetting-before-publishing (one of the defining characteristics of news),
> > I'm not aware of it.  In fairness, Wikipedia might plausibly claim to
> have
> > some expertise in dealing with the consequences of /not/ vetting before
> > publication, and those consequences are legitimately of interest (but I
> > agree the passage abound lending expertise cries for explanation; there's
> > irony in talking about propaganda in a piece on the wikimedia blog, which
> > tbh I consider a Foundation propaganda outlet).
> >
> > On Sat, Apr 8, 2017 at 3:50 PM, Rogol Domedonfors <domedonf...@gmail.com
> >
> > wrote:
> >
> > > On a related note, the Foundation Blog
> > > https://blog.wikimedia.org/2017/04/07/misinfocon-fake-news/ proudly
> > > announces that "the Wikimedia Foundation joined a handful of media
> > > organization at the MIT Media Lab to lend their expertise at
> MisInfoCon".
> > > That's certainly good to hear, but a little short on details  In the
> > > interests, of transparency, please could someone post a pointer to a
> > fuller
> > > description of the expertise that the Foundation has in this area (as
> > > opposed to the community of volunteers), and a pointer to the
> > submissions,
> > > papers or other contributions that those experts made at the meeting?
> > >
> > > "Rogol"
> > >
> > > On Wed, Apr 5, 2017 at 11:31 PM, wiki.pine <wiki.p...@gmail.com>
> wrote:
> > >
> > > > FYI: https://nonprofitquarterly.org/2017/04/04/new-nonprofit-
> > > > consortium-will-focus-countering-fake-news-building-trust-media/
> > > > Involved parties include some names that will be familiar to
> > Wikimedians
> > > > and WMFers: "AppNexus, Betaworks, Craig Newmark Philanthropic Fund,
> > > > Democracy Fund, Ford Foundation, John S. and James L. Knight
> > Foundation,
> > > > Mozilla, and the Tow Foundation."
> > > > Pine
> > > > ___
> > > > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > > > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > > > wiki/Wikimedia-l
> > > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > > Unsubscribe: https://lists.wikimedia.org/
> mailman/listinfo/wikimedia-l,
> > > > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> > > ___
> > > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > > wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> >
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] "News Integrity Initiative" at CUNY

[pi zero]

English Wikinews took serious measures for reliability back in 2009.  For
our pains, we've received mostly grief from the Foundation, and from a
vocal segment of the Wikipedian community.  If they consulted, before this
expertise-lending, with the sister project that specializes in
vetting-before-publishing (one of the defining characteristics of news),
I'm not aware of it.  In fairness, Wikipedia might plausibly claim to have
some expertise in dealing with the consequences of /not/ vetting before
publication, and those consequences are legitimately of interest (but I
agree the passage abound lending expertise cries for explanation; there's
irony in talking about propaganda in a piece on the wikimedia blog, which
tbh I consider a Foundation propaganda outlet).

On Sat, Apr 8, 2017 at 3:50 PM, Rogol Domedonfors 
wrote:

> On a related note, the Foundation Blog
> https://blog.wikimedia.org/2017/04/07/misinfocon-fake-news/ proudly
> announces that "the Wikimedia Foundation joined a handful of media
> organization at the MIT Media Lab to lend their expertise at MisInfoCon".
> That's certainly good to hear, but a little short on details  In the
> interests, of transparency, please could someone post a pointer to a fuller
> description of the expertise that the Foundation has in this area (as
> opposed to the community of volunteers), and a pointer to the submissions,
> papers or other contributions that those experts made at the meeting?
>
> "Rogol"
>
> On Wed, Apr 5, 2017 at 11:31 PM, wiki.pine  wrote:
>
> > FYI: https://nonprofitquarterly.org/2017/04/04/new-nonprofit-
> > consortium-will-focus-countering-fake-news-building-trust-media/
> > Involved parties include some names that will be familiar to Wikimedians
> > and WMFers: "AppNexus, Betaworks, Craig Newmark Philanthropic Fund,
> > Democracy Fund, Ford Foundation, John S. and James L. Knight Foundation,
> > Mozilla, and the Tow Foundation."
> > Pine
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Community Wishlist Survey: Top 10 wishes of 2016!

[pi zero]

Just a general observation:  Making things "global" can be good or bad for
non-wikipedia projects depending on how it's done; spreading uniformity
across projects could also damage non-wikipedia projects by imposing
inappropriate infrastructure.  I'm not totally cynical about the idea, just
noting one needs to be careful.  (A case that comes to mind:  I use HotCat
all the time on Wikinews, which in some important ways is as different from
Wikipedia as a wiki can be, yet HotCat is atm inappropriate for Wikibooks
and could cause problems there.)

On Fri, Dec 16, 2016 at 12:05 AM, James Heilman  wrote:

> Great to see so many that will benefit more than
> just the EN WP community such as global gadgets, non-Latin language
> improvements and global settings.
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Direction] WMF Board of Trustees 2016 priorities

[pi zero]

While I as much as any hope for positive developments in relation to the
board, and certainly it's good to hear of enthusiasm and recognition of the
need to improve the board, if I might inject a note of caution.

Every trustee acknowledges that there's a clear need for the Board to
> assume a leadership position for our movement.


I suggest it is not even /possible/ for the Board to assume a leadership
position for the movement, and that the Board's efforts to do so over the
past ten years have been damaging to the movement.  The core idealism of
the movement --- the thing that drives volunteers to donate passionate
labor, which can only be driven by idealism --- is, I maintain, that
information providing should be in the hands of The People; a fundamentally
bottom-up ideal.  The more the centralized WMF tries to direct things, the
more it conflicts with the ideal in fact; and the more it is /seen/ to try
to direct things, the more it saps the desire of volunteers to donate labor
because it seems less like pursuit of the ideal.  If the WMF has a useful
role to play in the movement, it is neither leadership nor top-down
software initiatives (which most of the current initiatives are).

It has also been clear in recent times that the Foundation has evolved a
corporate culture that self-justifies some of its most unfortunate
attitudes, and in this regard I admit I am unsettled when I see statements
such as


> We must not shy away from those challenges, nor from the decisions we have
> to make.
>

From the outside, I honestly can't tell whether to cheer or cringe. This
would be a good attitude to take toward various necessary changes to the
Foundation, yet it also sounds like the reasoning that was used, not long
ago, to justify a position that any volunteers who disagree with the
Foundation's dictates should leave.

Within the Board of Trustees, Maria Sefidari and I take the lead on  the
> necessary steps are being taken. Katherine and Foundation staff already
> have worked on the first steps to reach that goal.
>
> Our goal is to make sure we — as a movement — will have a strategy that we
> can all embrace and push forward together.


I do hope that everyone together can find a positive way forward (says the
optimist in me, even while the pessimist in me lists all the things likely
to go wrong).

Pi zero
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Superprotect is gone

[pi zero]

On Fri, Nov 6, 2015 at 10:51 AM, Neil Harris  wrote:

> That's fantastic, represents a huge vote of confidence for the Wiki Way,
> and is a big move towards improving the relationship between the WMF and
> the community.
>

Just to keep things in perspective: the removal of superprotect (which is,
granted, not the only action described) is a rather minor and only mildly
positive step.  Compare it to what should have happened: superprotect
*should* have been removed a year ago along with a profuse apology
acknowledging that it should never have been imposed in the first place.
Instead, it's removed a year later with the remark that "We have not used
it for resolving a dispute since. Consequently, today we are removing
Superprotect from Wikimedia servers" (05/11/15 17:35, Quim Gil wrote).  In
other words, it wasn't removed because it shouldn't have been imposed in
the first place, but merely because it wasn't used.  Is it good that it was
removed?  Sure, it's better to have had it removed than not.  But it's a
cheap token gesture.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Building a we in the wikimedia movement

[pi zero]

I agree with a bunch of what you're saying here.  That's probably worth
saying up front, because I'm going to disagree with a bunch of it, too.


 to assume good faith.


Assume good faith, and nearby concepts such as be civil, have in the
long term severely damaged the social infrastructure of the projects.


 I believe that with a strong inner peace conflicts
 would be less, the atmosphere would improve, and the so-called editor
 decline would be a problem of the past.


I agree that the editor decline is due partly to toxic social atmosphere
(mostly, in my experience, on Wikipedia; the smaller sisters are homier,
though of course it's hard to know how much of that is simply because
they're smaller).  Hopefully it's clear that there no way to externally
enforce inner peace, and I suggest that attempting to do so is a major
source of social toxicity.


 That goodwill can be cultivated at upper levels too.


Maybe.  Not through assume good faith, though, which merely gives upper
levels an excuse to ignore things they don't want to hear.


 Sometimes there are
 decisions that must be taken to improve our sites, and some of them have

created a lot of drama which maybe could have been minimized by enabling
 expression spaces, where there can be some real communication happening,
 that is, bidirectional, and not to force any ideas, just to foster
 understanding.


That's a key mistake of reasoning, right there.  The Foundation making bad
decisions is a problem because the decisions are bad, and any resentment is
a secondary concern.  The Foundation cannot help making, statistically, bad
decisions.  The Foundation is intrinsically less qualified than the
contributors to make decisions about what direction is in the best
interests of the sisterhood; the Foundation's unilateral judgement cannot
help being mostly worse for the sisterhood than the contributors'
judgement.  Can the contributor base make bad decisions?  Sure, but the
Foundation is at least as likely to be wrong about when that's going to
happen as they are likely to be wrong about anything else.

That is, the problem isn't that the Foundation needs to find a better way
to liase with the contributors about situations where the Foundation must
make unilateral strategic decisions, the problem is that the Foundation is
under the delusion there are situations like that.  The problem can't be
addressed by helping the Foundation to make better unilateral decisions,
because it's not possible for the Foundation to be enabled to do so.  The
problem can't be addressed by improving Foundation-contributor relations,
because that doesn't make the Foundations' decisions less damaging to the
infrastructure.


 In the wikimedia movement there is a serious lack of said expression
 spaces. For instance, during the WMCON 15, it was the first time that user
 groups representatives seated down together, also with some WMF employees,
 to discuss user groups in an open manner. I think it is a big step forward
 which paves the way in other areas too.


Communicating is much better than not communicating.  The Foundation
institutionally recognizing its limitations is badly needed.


 There is for instance the need to create roads for users to progress in the
 movement, to bring users from casual reader to a wise wikimedian
 status.


Now, that is very true.  One really good thing to do for that would be to
consistently emphasize users working directly with wiki markup (which
teaches by exaemple, something systematically prevented by WYSIWYG), and
consistently emphasize everything being done in wiki markup rather than
separate languages such as Lua or JavaScript (or, FSM help us all, PHP).


 Such a wise people already exist in our movement, it is a pity that
 we don't enable more knowledge transfer between the elders and newcomers,
 because when one of our wise wikimedian (digitally) dies, it leaves behind
 a big gap which is very big to fill up again.


Capturing contributor experience, enabling it to be applied and transferred
to newcomers, is what I mean to accomplish with my dialog tools
https://en.wikinews.org/wiki/Help:Dialog.  I mean to transform wiki
markup into a medium that can make wikis crowdsourced repositories of
know-how about wikis for contributors as well as of knowledge for readers.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Wikinews and free journalism

[pi zero]

It would scarcely be possible to overstate how un-seriously Wikinews takes
Signpost's coverage of Wikinews.  We typically don't even bother to try to
debunk falsehoods about Wikinews when they appear on Signpost, figuring
they're too numerous and the forum is too biased for meaningful dialog.

Of possible interest:
* http://ro.uow.edu.au/lhapapers/428/
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

On Thu, Oct 9, 2014 at 7:53 PM, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 Finally, I consider the unreadable parser functions problem essentially
 solved.  Lua is not perfect, but it's a usable language (and not a
 Mediawiki-specific one) that is far more readable and writable than
 complicated nested parser functions.


I see replacing unreadable parser functions with Lua as replacing one
bad solution with a differently bad solution.  Since the problems of the
second are different from those of the first, it's possible to claim the
second solves the problems of the first, but that's a bit lame.  The
problems of Lua should have been anticipated, and should have been avoided
by finding a better solution; and settling for a differently bad solution
is just a different way of settling for a bad solution.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

On Tue, Sep 2, 2014 at 5:40 AM, Martijn Hoekstra martijnhoeks...@gmail.com
wrote:

 tl;dr: We've been collectively whining about templates for long enough. Who
 wants to help with fixing them?


Improving on templates is broadly what I've been doing with my dialog tools
https://en.wikinews.org/wiki/Help:Dialog, which I've been working on for
about three years and am hoping to start using seriously pretty soon (I've
got a few more tweaks in mind to do first; after that, further improvements
I expect to be driven by experience with serious use).  I've been
developing these tools using javascript under the hood, although I'm sure
they could in theory be done better as a wiki extension, because I reckoned
the design would need to be able to turn on a dime and I'd observed the
wiki-extension approval process was, well, not.

The dialog tools mediate passing data from page to page, using elements
specified using wiki markup, with the particular intent that a wiki
community could use these tools to crowdsource wizards
https://en.wikipedia.org/wiki/Wizard_%28software%29 entirely written in
wiki markup.

Data is entered using input elements such as text boxes and dropdown menus,
then passed to the next page via buttons, all placed via templates like
{{dialog/textarea}}, {{dialog/button}}.  At the receiving page, dialog data
can go into other input elements, but can also be substituted for template
parameters, and expressions using template-expansion can be used to specify
values for input elements, so that the whole thing meshes tolerably well
with the template system rather than competing with it.  Each
{{dialog/button}} specifies an action to be performed.  The usual action in
the middle of a dialog is view, to display a page, but there's also an
action edit --- hedged around with safeguards against abuse, of course;
safeguards predicated on the assumption that admins are trustworthy.

In designing dialog-action edit, I uncovered something curious that hints
to me (as a programming-language designer) that the whole concept of wiki
templates might have been subtly flawed... though I don't imagine the flaw
could have been anticipated at the time, and I agree wholeheartedly that at
this late date, not breaking things is paramount.  With the API edit
action, there's an optional preload page; and I'd originally imagined that
for dialog edit I'd want to allow the preload page to take template
parameters; but when I actually started creating dialog edit, keeping in
mind the sorts of wiki activities I was familiar with that one might want a
wizard for, I realized that it was more natural to provide a form page
that would be fully template-expanded to produce the raw content for the
edited page.  In techspeak, this difference between preload pages with
template-parameter substitution, versus dialog-edit forms with full
template-expansion to generate raw content, is essentially that the preload
page is a macro
https://en.wikipedia.org/wiki/Macro_%28computer_science%29#Syntactic_macros,
while the dialog edit form is a fexpr https://en.wikipedia.org/wiki/Fexpr.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

To be clear, ordinary user of the dialog tools most certainly does *not*
involve knowing javascript or Lua or html.  The whole point is to arrange
that an ordinary wiki users can do wonderful things using *only wiki markup*.
(The hypothetical example of a url there is, btw, entirely wrong; but one
wouldn't write any sort of url anyway.)

The syntax for specifying a typical button would be more like
{{dialog/view|page::Name of page}}, but most people wouldn't even have to
figure that much out for themselves --- they would copy-and-modify somebody
else's markup they'd found somewhere that did something similar to what
they wanted, and they'd use common sense for how to modify it.  That's part
of the great strength of wiki markup:  you do simple things, and while
doing them you see other, slightly more advanced things that others have
done, so later on when you find you want some of those slightly more
advanced things, you've seen them before and know where to look for
examples.

Yes, there is in fact a lisp interpreter written in Lua.  It makes up for
some other weaknesses of templates.  I expect most users not to have to
touch that most of the time, and when they do they'll usually be able to
just copy others' markup and make slight, obvious modifications.  It's so
vastly handy that I've used it (you've reminded me) in some of the dialog
templates, just because it's so much easier to do things with it.  I
created it because it was obvious I'd need a powerful succinct way, without
the cumbersome notational overhead of templates or Lua (or JavaScript,
perish the thought), to specify transformations of the raw content of a
wiki page; and the one place thus far where I use it intensively is for
just such an application (removing from a wiki page all template calls of
one kind, and modifying all those of another kind).  I expect to be able to
readily build tools, using dialogs and that lisp interpreter, to do things
of the same general order as HotCat (only more sophisticated), and given
the contrast between a few lines of Lisp and the JavaScript source code for
HotCat, I think I'm quite justified in considering it an improvement... if
it proves out.  (There is some question whether this technique as currently
implemented will really scale to manipulating the whole content of large
wiki pages, due to practical limitations that may be imposed on the dialog
tools by... the template-handling of the wiki software; but we'll see at
what scale that becomes a problem, an what might be done under the hood to
move the threshold when encountered.)

I do agree that templates are rather broken, although frankly the
Foundation could --- with some deep insight --- have done things that would
have improved them.  The current plethora of magic words is a mess, partly
because the template call-syntax is heavy and pure template/magic-word
usage keeps sending things back to typeless text; both of which problems
are not shared by my embedded lisp interpreter, with it's very-low-overhead
call syntax and its simple, minimal, but highly useful dynamic type system.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

On Tue, Sep 2, 2014 at 12:00 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 That would take a more detailed look at what is actually trying to be
 accomplished with these dialogs. For example, enwiki's Teahouse[1] has a
 dialog for newbies to more easily post questions, but it's implemented as a
 gadget that generates the form specific for that page. To what extent to we
 have actual use cases for many differently-designed dialogs? How does the
 lisp even enter into the current design?


The part about lisp, perhaps I've addressed in the other message I just
posted (though it seems to have gone off with a distressing number of typos
in it).  And as for looking at examples of dialogs --- I agree, and I
/don't/ have examples, exactly because this storm over superprotect has
been precipitated by the Foundation /before/ I'd really intended to go
widely public with my tools.  I've decided people should be aware of what
I'm doing even though I'm not quite there yet, but honestly, the primary
route I'd always envisioned, to convince people that my ideas were viable,
was to /demonstrate/ it, by building the tools and then starting to use
them to build wizards.  This is what has always worked best for me in the
past:  if I can see the potential in a low-level tool, the best way to show
others the potential I see is to make it real.  It's taken me an appalling
amount of time (three years) to develop the tools, partly because at every
little step in the design I've stopped to consider the implications for
practical applications (like the difference between carving a statue by
hand-and-eye with a hammer and chisel, versus pouring cement into a mold).
Which I suppose is another part of my contention that design decisions
about wikis should be made in the field.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

On Tue, Sep 2, 2014 at 12:41 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 This reply still isn't anything official, but does represent my own views
 as a developer (both volunteer and staff)

 Is there an actual problem with Scribunto that drove you to writing this
 lisp interpreter, or is it just that you don't like the fact that Scribunto
 forces you to separate Lua code from templates?

 I consider this separation a good thing, as even if it is more work for the
 developer it makes things much easier for everyone else to understand
 later.


I have a specific reason for disapproving of the separation.  Wiki markup
was incredibly successful; that's why there /is/ a wikimedian movement.
It's not all been made to happen by flower-power.  The two key
characteristics of wiki markup that, I believe, made it work so
spectacularly well are (1) It's very easy to use.  It can get to be
something of an awful mess at the high end, when the subtly design-flawed
template mechanism gets forcibly overused, but when you get down to it,
wiki markup is easy --- especially when one takes into account the second
key characteristic, (2) it naturally promotes incremental learning.  A
while back I had a really simple edit to make to a Wikipedia page, and
thought I'd try out VisualEditor on it.  Eventually I gave up and did it by
editing the markup.  What I'd wanted to do was to add another simple item
to an itemized list.  The point here isn't how to do that, directly; the
point is, even if I'd been a newbie with no clue how to do that, I'd have
had no problem whatsoever with doing it in the absence of VE, because when
I edited the markup, I'd have had examples right there in front of me of
exactly how to do it.  And as I think back, I learned just about everything
I know about wiki markup that way.  My first few edits were correcting
typos, and I saw how wikilinks were done, and so on.  At each stage, I'd
seen examples of things just a little more advanced than what I'd done
myself, because it was all right there in the markup I'd been editing, and
when I wanted to do a little more than I had I'd go see how others had done
similar things.  But Lua is a completely different sort of language,
requiring a major step --- and major steps don't belong to the wiki
development pattern.  Wikis work using volunteer labor because of their
incremental approach, both to editing and to /learning/ to edit (and to
learning how to participate in the community, but that's another subject).

And, Lua is a high-overhead language.  You can't just write super-simple
expressions and have them work, and build other stuff up.  Lisp, on the
other hand, has extremely simple, unambiguous, low-overhead syntax.  (Even
simple template calls have more syntactic overhead than lisp function
calls.)

Of course, my primary goal was interactive pages, for building wizards, and
it was clear to me that Lua wasn't going to help me with those anyway.

 I do agree that templates are rather broken, although frankly the
  Foundation could --- with some deep insight --- have done things that
  would have improved them.  The current plethora of magic words is a mess,
  partly because the template call-syntax is heavy and pure
  template/magic-word usage keeps sending things back to typeless text;

 The Foundation *did* do something. It's called Scribunto.


Scribunto which I maintain is, for the reasons I've attempted to
articulate, philosophically incompatible with the factors that make wikis
successful.  I might add, that I believe these things are /still/ an
essential ingredient for making wikis successful, and each time the wiki
experience is changed in a way that moves away from those factors, the
long-term success of the movement is degraded.

Scribunto isn't an improvement to templates; it's trying to half-replace
them with something else.  My understanding of improve templates would
exclude a half-replacement (or full replacement), even if the
half/full-replacement were to improve *on* templates.  (Actually, I do
think Scribunto is an improvement on the status quo ante, but there are
other routes that would have also been improvements on that, that I believe
would have been better for the long-term health of the wikimedian movement.)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

[pi zero]

Pardon my long reply; I actually meant to just comment on a couple of
things, and got carried away.  But I really do find this topic very
interesting.

On Tue, Sep 2, 2014 at 2:03 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:

 When it comes to your extremely complicated templates with embedded lisp,
 you're losing *both* of these.


The templates are extremely complicated in implementation, which is
irrelevant.  If templates were rejected based on extremely complicated
implementation, that would rule out essentially everything that uses
Scribuntu under the hood.

We already have user studies (which I don't have the links for offhand) that
 show that people see the relatively simple infobox templates in articles
 and give up.


Heh.  Studies.  Complete this phrase: Lies, damn lies, and... :-P
Seriously, though, I know from direct observation there are people who have
trouble with templates comparable to Wikipedian infoboxes; of course, named
parameters are a rather baroque aspect of template call syntax, which I've
already remarked is not as light-weight as one could wish.  (Although in my
experience most people don't get it overly wrong, and after being shown
once what they'd not quite gotten right, usually don't get it wrong
again.)  It does seem a bit surprising to suggest that somebody who can't
figure out how to fill in the blanks in an infobox would be more able to
write in Lua.

The advantage to having the complexity of Lua in modules is that the
 complexity specifically is hidden from new users. Once someone gets to the
 point where they're ready to make that step, they're probably motivated
 enough that looking through the manual (or even better would be if someone
 would write some good tutorials) isn't likely to be the barrier it would be
 to a complete newbie.


Tutorials are a /horrible/ way to convey information.  As are manuals.
This is one of the key weaknesses of wikis, I think, that they're atrocious
at passing on wiki-expertise.  Users can learn some things by the
incremental path I've described, but beyond that, wikis naturally fall back
on documents, because that's all the wiki software is good for specifying.
Documents.  Afaik, /all/ the sister projects complain that they provide
these carefully written welcome templates that explain all about how to do
things on that project, and nobody reads them.  New variant on RTFM.  I
once put a welcome template on a newcomer's user talk on en.wb and they
actually complained to me about it, saying they'd been to lots of different
sister projects and they all annoyingly insisted on /welcoming/ them,
they'd been welcomed to death, cut it out already.

What I think /can/ work is an interactive wizard, where at every step the
advice/help for that particular step is right there, in-your-face.  Hence
my intent to provide tools that enable wiki communities to build their own
wizards, completely cutting out the middleman (because the wiki community
is where the expertise already resides, and wikis thrive on just-do-it,
cutting out the middleman).

I don't think most users are going to progress from wiki markup to Lua.
Certainly it requires a deeper commitment than the sort of incremental
progression I'm advocating.  And lowering the bar for participation is also
part of what wikis are about.

Sure you can; a little boilerplate is needed, but both that and the
 language itself are simple enough that someone could start from some basic
 examples and experiment easily enough.


Oh, lol.  What was that you were saying about cargo-cult programming?
(This is meant as /good-natured/ ribbing.  I invite you to laugh with me.)

Seriously, cargo-cult programming, or the equivalent, is how much of wiki
contribution works (I suppose we shouldn't open the
cargo-cult-professional-programming can of worms).  Somebody with deeper
understanding might come along later and improve things, and that's good
too, but that's later.


 On the other hand, Lua's syntax and operation is similar to that of C, PHP,
 JavaScript, and so on, which are likely to be familiar to users with some
 sort of programming experience.  While parser function syntax somewhat
 resembles Lisp, I'm not sure that similarity will help with understanding
 more than the surface.


I mean to avoid cutting off the long tail of users who /don't/ have some
sort of programming experience. I'm not worried about those whose
experience somehow leaves them able to figure out Lua but not minimalist
lisp; I'm not sure that's even a nonempty set, and if it is I doubt it's
all that significant.   Give me your huddled masses yearning to breathe
free any day.  Also, most of them don't have to understand more than the
surface.

I'm not also sure that Lisp's extremely simple syntax is necessarily an
 advantage. While extra syntactic structure requires extra learning, it also
 means that the written code is more structured which may be easier for
 humans to make sense of. Again, look at the trouble people report in

Re: [Wikimedia-l] Let's fix templates

[pi zero]

On Tue, Sep 2, 2014 at 2:25 PM, Marc A. Pelletier m...@uberbox.org wrote:

 On 09/02/2014 01:35 PM, pi zero wrote:

  (1) It's very easy to use.
  (2) it naturally promotes incremental learning.

 I'm sorry, but both of those assertions are not only wrong, but
 profoundly misguided.


At first I thought, well, seems safe to assume /we're/ not going to agree.
And of course I still think that.  But it sees there may more going on here
than a disagreement about the user experience, in that we may have somewhat
different understands of what we're talking about.

I would be surprised if it represented even a tenth
 of a percent of today's Internet users.


This is mostly simple disagreement, but may edge into the second point; my
first thought was that you're giving people too little credit... but on
second thought, I wonder if you're, more specifically, assigning discredit
to people that belongs to accidental characteristics of the interface.  And
then there's this last bit:

  The only reason templates were a success[1] is because the original
 wikipedian self-selected by their ability to grok and manipulate those
 concepts.


 [1] Furthermore, even /whether/ templates were a success is highly
 debatable.  If I look at the current mess, and the troubles caused by
 it, I doubt it.  I'd argue that we did great things /despite/ templates
 as a mechanism, not because of it.


Now, just incidentally, besides skepticism on the point about
self-selection, I'm also not altogether convinced it /matters/ either way
since the result was hugely successful.  But what really gave me mental
whiplash was the apparent supposition that someone here thinks templates
were a success.  I'm satisfied we disagree on the manageability of
elementary template syntax, but... templates a success?  I'm not sure where
we're talking past each other, but it's happening somewhere.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)

[pi zero]

On Thu, Aug 7, 2014 at 3:33 AM, Quim Gil q...@wikimedia.org wrote:

 I think the core of the problem is how to increase the participation of
 tech-curious contributors, and how to structure it in a way that informs,
 influences, and actually joins the development process effectively.

 How can we increase the participation in technical matters among Wikimedia
 editors and readers?


Fwiw.  My approach for this is based on simple fundamental properties of
the interface (which I believe to be responsible for the success of wikis
in the first place).  Based, at least in part, on my own experience, I
believe the key to giving new contributors a path to gradually increasing
involvement is takes a deep breath to have everything be done by directly
editing wiki markup.  Seriously.  This has been my experience.  You start
out doing some very simple things like correcting a misspelling.  Because
you are actually editing the wiki markup, as you correct that spelling
error you can see how other wiki markup is structured, that others have
written.  As you get more involved, from time to time you choose to
exercise some slightly more advanced technique you knew was possible, and
had some broad notion how to do, because you'd seen that others were doing
it, and you'd seen how they did it.  And so on.

You may notice that this vision of what promotes gradually increased
participation is in direct conflict with the idea of Visual Editor.  My
premise implies that Visual Editor undermines (incidentally, for this
thread) the core infrastructural advantage that makes wikis a successful
concept.

In order to extend this gradual-advancement path into the sharing of
community expertise in how to perform technically complicated tasks ---
which I see as a major need of all the wikimedian sisters --- I had the
idea of creating a set of templates (thus, keeping things within the
purview of wiki markup) for adding interactive elements to wiki pages:
text boxes, radio buttons, menus, and *buttons* that pass the contents of
those text boxes to actions that do things with them:  feeding them into
other pages as input-element content, as template parameters, and as new
(or initial) content in page edits.  I've been at this for... I guess it's
three years now, creating these basic facilities with a mix, under the
hood, of wiki markup, javascript, html, and (recently) lua.  Although it
was obvious from the start this would be most efficiently done as a wiki
extension, I reckoned (sorry to be blunt) the development process for wiki
extensions was stacked against anything that doesn't cater to central
authority's notion of what would most benefit Wikipedia.  (Yes I worded
that deliberately, though cynically; I've acquired my cynicism by watching
what actually gets done over the six or seven years since I got
sufficiently involved with wikimedia to notice.)  Fwiw, after three years,
I'm just about ready to start trying to use my tools for some serious
applications; yonder https://en.wikinews.org/wiki/Help:Dialog.

Pi zero
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Please rename this list to shitfight-l, and give us a list where civil discussion about wikimedia can take place

[pi zero]

 I am looking for a productive mailing list that discusses matters of
 importance to the Wikimedia community. That the people on such a list can
 have these discussions politely, respectfully, and with concern for others
 in that the words that say, and attitudes taken.  I want to see
 announcements, I want to see a higher quality of conversation on what
 should be a flaglist in the mailing list space of Wikimedia.


Producing civil discourse isn't easy.  I was very impressed by AGF when I
first arrived at Wikipedia, and it's taken me some years to realize it goes
badly wrong in the long term; protects refined trolls, who learn to use it
as a shield against accusations of bad faith and a weapon against those of
good faith whom they manage to provoke.  The opposite extreme may only work
under special circumstances --- Never assume
https://en.wikinews.org/wiki/Wikinews:Never_assume works tolerably well
for en.wn, but Wikinews has the advantage that most discussions can't
meaningfully drag out anyway because most issues of contention would be
unpublished articles, which rapidly go stale and become irrelevant (so that
partial moderation of discussions is afforded indirectly by en.wn's
article-review workflow, which is more nearly objective than a direct
discussion-moderation).  Arguably, AGF shows that fully distributed
moderation doesn't work, while Never assume only shows that weak direct
moderation can work if there's an external factor imposing order.  The
internet is a dangerous place
http://www.slate.com/articles/health_and_science/climate_desk/2014/02/internet_troll_personality_study_machiavellianism_narcissism_psychopathy.html
and one wants a set of rules for moderating internet discussions that is
radically inclusive of those of good faith but wildly different views,
exclusive of troublemakers, and objective enough to be enforced
consistently and successfully by many different moderators of good faith.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe