Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@uberbox.org wrote: On 07/29/2013 07:00 PM, David Gerard wrote: Are there any wikitext constructions that are actually going to be deprecated? I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2 Getting it rid of /just/ that would lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity. And probably would make most of the VE team cry in relief. -- Marc ___ Wikimedia-l mailing list 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 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] WMF 2013 elections post-mortem
Dear all, Risker has prepared a detailed report of the 2013 elections outlining several of the challenges that the Elections Committee faced this year. https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2013/Post_mortem/Report_from_Risker#Discussion_6 My report as board liaison is on the talk page at: https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_elections_2013/Post_mortem/Report_from_Risker Both these need serious movement-wide discussion. Please add your thoughts and comments so that we may consider various possibilities and act to strengthen the election process before it recedes from our consciousness. Best Bishakha ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 07:39, Martijn Hoekstra martijnhoeks...@gmail.com wrote: I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2 D-: That's like a story parents tell VE developers to scare them into behaving. - d. ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
Beside being way more effort than it is worth, what is particularly Lovecraftian about that? Cheers, Peter - Original Message - From: Martijn Hoekstra martijnhoeks...@gmail.com To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Sent: Tuesday, July 30, 2013 8:39 AM Subject: Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor) On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@uberbox.org wrote: On 07/29/2013 07:00 PM, David Gerard wrote: Are there any wikitext constructions that are actually going to be deprecated? I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2 Getting it rid of /just/ that would lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity. And probably would make most of the VE team cry in relief. -- Marc ___ Wikimedia-l mailing list 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 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 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@uberbox.org wrote: On 07/29/2013 10:02 PM, Rschen7754 wrote: If I'm reading this right, it *would* cause massive problems on the English Wikipedia Oh, it *would* if the syntax was just disabled outright! Now, if it were me that was in charge of fixing wiki markup, this is what I would do: (a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable. Something like the following process might be a little easier on the projects. Assuming that ultimately want each page to be a valid fragment, suitably defined: Introduction period: 1. Deprecate the alternative *right now*, by publicly announcing what it is exactly we would rather not see exist, wikitext wise. 2. Start engaging the projects, and set up wikiprojects that are responsible for finding the cases where no reasonable alternative for the current legitimate uses is, and work on expanding the language to make sure these cases are covered as well as being responsible for setting up forums for getting help on how to migrate away from depricated syntax. Transition period: 3. For a suitably long time, display a warning when such a page is saved, refering users to the local working group that can help them learn how to write New Wikitext. More legitimate uses will emerge, and reasonable alternatives must be found or created for everything we are able to do now. 4. Block the creation of new templates with deprecated syntax. Also block saving templates that were free of deprecated syntax would an edit introduce deprecated syntax. 5. When the wikiprojects are no longer buckling under the load of the stream of unimagined creative and useful yet horrible uses of wikitext they didn't forsee, and a good deal of templates have been fixed, start showing warnings when saving pages that transclude pages with deprecated syntax. Repeat the above steps of waiting and fixing. 6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry. 7. Deal with the outcry by making a list of things yet to be fixed. Move the deployment date to a month after all* bugs have been closed. 8. Block saving pages that contain brokenness. Expect outcry. If outcry, roll back and go to 7. 9. With sufficient technical ingenuity, freeze and archive the dark legacy. Don't make it mix with the brave new world. 10. Celebrate successful deployment, and wish each other a happy 2020. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable. *: for a sufficiently reasonable value for all. Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad. -- Marc * This would include, indirectly, the code fragment templates like Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny. ___ Wikimedia-l mailing list 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 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] Questions for the WMF Board of Trustees?
Hi Lodewijk, I like the idea of having more opportunities to talk and to try out different approaches. That was the reason for Patricio and me to offer a Chapters Lunch Meeting on Sunday, where we want to talk about the role of Chapters Selected Board members, expectations, limitations, and the relationship we have. I read your suggestion like something similar, concentrating more on particular issues and diving somehow deeper into the subject. And yes, I would be glad to participate if it matches with my schedule. Alice. On Tue, Jul 30, 2013 at 7:34 AM, Bishakha Datta bishakhada...@gmail.comwrote: On Mon, Jul 29, 2013 at 8:20 PM, Lodewijk lodew...@effeietsanders.org wrote: Hi Phoebe, thanks for pointing to this! I see that this year we only have one hour of board QA. I have always seen a lot of value in these board discussions, especially when it can come to actually that: discussions. As there are several discussion sessions scheduled, without a specific topic, would you and perhaps a few other board members be willing to commit to use some of these sessions to dig a bit deeper into a few specific topics? For example, would there be three board members willing to have a round table discussion about transparency and openness at a board level? I'd be interested in participating in this one - but cannot take the lead on making it happen. Do let us know if this does get fixed during wikimania. Cannot make it 9 Aug 2-4 when there's another meeting, but open to other times. Best Bishakha 2013/7/29 phoebe ayers phoebe.w...@gmail.com Hi all, Every year at Wikimania the Wikimedia Foundation Board of Trustees hosts a panel where they take questions from the audience on the work of the WMF and the Board. In past years the board has also taken questions via IRC. This year we'd also like to provide the opportunity to leave questions on a wiki page ahead of time: http://wikimania2013.wikimedia.org/wiki/WMF_Board_Q%26A While there is only time to answer a few questions during the session itself, hopefully this will be a good way of getting questions from attendees as well as from those who can't make it. The board will also take questions from the audience at Wikimania, as time permits. Remember the Board doesn't deal directly with work on or problems on the projects, and does not have a direct hand in how the WMF operates day-to-day. Rather, the board thinks about the big picture, and gives direction on strategy for the WMF. You can find out more about what the board does (and does not do) here: http://wikimediafoundation.org/wiki/Board_of_Trustees and http://meta.wikimedia.org/wiki/Board_handbook best, phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikimedia-l mailing list 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 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 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 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 9:36 AM, Peter Southwood peter.southw...@telkomsa.net wrote: Beside being way more effort than it is worth, what is particularly Lovecraftian about that? Cheers, Peter What's bad about it, is that the meaning of the transcluded content changes radically on the context into which it is transcluded. What's Lovecraftian about it is that it changes the syntactical meaning of elements on the page that it is transcluded in to, without even having to be near it. --Martijn A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? - Original Message - From: Martijn Hoekstra martijnhoeks...@gmail.com To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.**orgwikimedia-l@lists.wikimedia.org Sent: Tuesday, July 30, 2013 8:39 AM Subject: Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor) On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@uberbox.org wrote: On 07/29/2013 07:00 PM, David Gerard wrote: Are there any wikitext constructions that are actually going to be deprecated? I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/**User:Martijn_Hoekstra/** Lovecraftian_horror2http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2 Getting it rid of /just/ that would lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity. And probably would make most of the VE team cry in relief. -- Marc __**_ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l , mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org ?subject=**unsubscribe __**_ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org ?subject=**unsubscribe __**_ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org ?subject=**unsubscribe ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 29, 2013, at 11:39 PM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2 Iä! Iä! Cthulhu Fhtagn! Seriously, awesome example. --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
snip
4. Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit
introduce deprecated syntax.
snip
Strictly speaking this is impossible. While there are some common
cases that could be recognizable on a per template basis, there are
other cases that are only recognizable as problems when placed in the
context in which the are used.
To give a ridiculous example:
A template {{foo}} consisting of Nothing here looks innocuous
enough until embedded in a page that reads div{{foo}}/div.
Because templates can contain tag, table, and other markup fragments,
the implications for the parser aren't necessarily clear until the
template is used in context with other elements. So one could
identify this as an issue when saving the page that uses it, but there
is no general way to identify all templates that might be problematic
at the time the template is written.
-Robert Rohde
___
Wikimedia-l mailing list
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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde raro...@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
snip
4. Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit
introduce deprecated syntax.
snip
Strictly speaking this is impossible. While there are some common
cases that could be recognizable on a per template basis, there are
other cases that are only recognizable as problems when placed in the
context in which the are used.
To give a ridiculous example:
A template {{foo}} consisting of Nothing here looks innocuous
enough until embedded in a page that reads div{{foo}}/div.
Because templates can contain tag, table, and other markup fragments,
the implications for the parser aren't necessarily clear until the
template is used in context with other elements. So one could
identify this as an issue when saving the page that uses it, but there
is no general way to identify all templates that might be problematic
at the time the template is written.
-Robert Rohde
Drat, you are clearly right. I was hoping there was a way to dream up a
transition where at no point a seperation between old syntax transcusion
and new syntax transclusion would have to be made until the very last
moment (my step 9 above). It should still be possible to find and mark
templates that are broken through a one time exhaustive search (find all
transclusions, and check if the generated DOM for the transcluded fragment
is identical to the generated DOM of the fragment itself) and make a split
there.
My first thought was that it would be completely unfeasible bordering
impossible to do that on every page save, but now that I think of it, while
it would undoubtably be very rough on the backend, for a cause as noble as
moving away from template madness it might be worth it ( a single extra
query and the number of inclusions extra full page parses - but some parse
results could be cached for a transitional period, and you can stop once
you have found one failing parse). The WMF devs should be far more able to
estimate its impact, but It's a little soon to discuss that, as the wish to
deprecate the current semantics hasn't even been officially stated.
--Martijn
___
Wikimedia-l mailing list
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
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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
When discussing issues like this. One should keep in mind that we
don't really want to be in the business of solving hard problems
simply by pushing the difficulties onto other people. Wikitext has
some characteristics that make parsing it hard (some might say
ridiculous). Changing wikitext will create problems elsewhere (and a
lot of work for volunteers). In addition one should be careful that
any changes are made in such a way that important workflows are not
made significantly harder for editors.
To give a common example, see {{nom}}, which consists of:
style=background: #FDD; color: black; vertical-align: middle;
text-align: {{{align|center}}}; {{{style|}}} class=no table-no2 |
Nominated
A clever person will quickly realize that this is used in a table context like:
{|
| Golden Globes || Best Actress || {{nom}}
|}
Where the {{nom}} template carries with it not just the text
Nominated but also part of the styling to be applied to the table.
This would seem to be a hard example to reimplement in a context
agnostic way. At present the template content only makes sense
because it is placed in the context of a wiki table. Getting around
that would seem to be awkward. You could try to fudge it by applying
the {{nom}} styles to something like a div block. However, placing
that block within the table cell would run the risk of cell padding
and other table properties causing conflicts or bad appearance, not to
mention that such an approach couldn't be used if the template is also
passing colspan / rowspan directives to the cell. Alternatively, one
would pretty much have to pull all or most of the table into the
template, which would seem to lead to new headaches and make the
source that is much more complicated for authors than the present
version.
This is one of the examples where there would seem to be few good
alternatives. Maybe the devs who are imagining reengineering wikitext
can also think up good alternatives for some of the uses they might
contemplate making obsolete?
-Robert Rohde
P.S. {{nom}} and its sister templates are an example of templates that
VE can't presently handle.
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is
what I would do:
(a) require that syntactic elements opened in a template be closed in
that template during transclusion* (without a change in code now; i.e.:
deprecate but not enforce yet).
(b) provide a mechanism by which templates which do this are
categorized/marked and otherwise findable.
(c) wait suitably long
(d) convert current invalid (according to (a) and identified by (b))
syntax by substituting still transcluded templates inline (thus not
breaking content)
(e) delete/blank/comment out those templates
(f) render the previous syntax invalid (by implicitly closing any
syntactic construct at the end of transclusion)
(g) provide a list of all the subst done in part (d) to the community so
that automated tools can fixup/convert/cleanup with new markup/LUA where
applicable.
Something like the following process might be a little easier on the
projects. Assuming that ultimately want each page to be a valid fragment,
suitably defined:
Introduction period:
1. Deprecate the alternative *right now*, by publicly announcing what it is
exactly we would rather not see exist, wikitext wise.
2. Start engaging the projects, and set up wikiprojects that are
responsible for finding the cases where no reasonable alternative for the
current legitimate uses is, and work on expanding the language to make sure
these cases are covered as well as being responsible for setting up forums
for getting help on how to migrate away from depricated syntax.
Transition period:
3. For a suitably long time, display a warning when such a page is saved,
refering users to the local working group that can help them learn how to
write New Wikitext. More legitimate uses will emerge, and reasonable
alternatives must be found or created for everything we are able to do now.
4. Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit
introduce deprecated syntax.
5. When the wikiprojects are no longer buckling under the load of the
stream of unimagined creative and useful yet horrible uses of wikitext they
didn't forsee, and a good deal of templates have been fixed, start showing
warnings when saving pages that transclude pages with deprecated syntax.
Repeat the above steps of waiting and fixing.
6. Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable. The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder* (Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.) [These are technical questions, but I think they have sufficient impact to discuss more widely, e.g. on this list. Assuming enough relevant devs are around to comment.] - d. ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde raro...@gmail.com wrote:
When discussing issues like this. One should keep in mind that we
don't really want to be in the business of solving hard problems
simply by pushing the difficulties onto other people. Wikitext has
some characteristics that make parsing it hard (some might say
ridiculous). Changing wikitext will create problems elsewhere (and a
lot of work for volunteers). In addition one should be careful that
any changes are made in such a way that important workflows are not
made significantly harder for editors.
my point three wasn't something trivial, and will require a heck load of
engineering (for refrerence:
3. For a suitably long time, display a warning when such a page is saved,
referring users to the local working group that can help them learn how to
write New Wikitext. More legitimate uses will emerge, and reasonable
alternatives must be found or created for everything we are able to do now.
)
To give a common example, see {{nom}}, which consists of:
style=background: #FDD; color: black; vertical-align: middle;
text-align: {{{align|center}}}; {{{style|}}} class=no table-no2 |
Nominated
A clever person will quickly realize that this is used in a table context
like:
{|
| Golden Globes || Best Actress || {{nom}}
|}
Where the {{nom}} template carries with it not just the text
Nominated but also part of the styling to be applied to the table.
This would seem to be a hard example to reimplement in a context
agnostic way. At present the template content only makes sense
because it is placed in the context of a wiki table. Getting around
that would seem to be awkward. You could try to fudge it by applying
the {{nom}} styles to something like a div block. However, placing
that block within the table cell would run the risk of cell padding
and other table properties causing conflicts or bad appearance, not to
mention that such an approach couldn't be used if the template is also
passing colspan / rowspan directives to the cell. Alternatively, one
would pretty much have to pull all or most of the table into the
template, which would seem to lead to new headaches and make the
source that is much more complicated for authors than the present
version.
I'm convinced that the MediaWiki devs will be able to device a way to do
this better. My markup and style foo is too weak to even speculate about
what that better may be like.
This is one of the examples where there would seem to be few good
alternatives. Maybe the devs who are imagining reengineering wikitext
can also think up good alternatives for some of the uses they might
contemplate making obsolete?
-Robert Rohde
When I said celebrate a happy 2020, it was a case of ha ha only serious.
There are easy nor quick fixes for these issues, and any change will not
only cost a lot of engineering, but will also require a lot of effort from
the communities to fix the breakages it will introduce, which is why I find
it so important to have this discussion long before engineering plans are
drawn up.
P.S. {{nom}} and its sister templates are an example of templates that
VE can't presently handle.
Which is why I think it is very important to have this discussion. I also
think I made my points on this thread and list to a sufficient level, and
will try to sit back and read what the people who really know what they are
talking about have to say about it.
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is
what I would do:
(a) require that syntactic elements opened in a template be closed in
that template during transclusion* (without a change in code now; i.e.:
deprecate but not enforce yet).
(b) provide a mechanism by which templates which do this are
categorized/marked and otherwise findable.
(c) wait suitably long
(d) convert current invalid (according to (a) and identified by (b))
syntax by substituting still transcluded templates inline (thus not
breaking content)
(e) delete/blank/comment out those templates
(f) render the previous syntax invalid (by implicitly closing any
syntactic construct at the end of transclusion)
(g) provide a list of all the subst done in part (d) to the community so
that automated tools can fixup/convert/cleanup with new markup/LUA where
applicable.
Something like the following process might be a little easier on the
projects. Assuming that ultimately want each page to be a valid fragment,
suitably defined:
Introduction period:
1. Deprecate the alternative *right now*, by publicly announcing what
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable. The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder* (Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.) This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now. [These are technical questions, but I think they have sufficient impact to discuss more widely, e.g. on this list. Assuming enough relevant devs are around to comment.] - d. ___ Wikimedia-l mailing list 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 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] [Wikimedia Announcements] Changes at the Wikimedia Foundation Fundraising Team
If I was recruiting colonists for an interstellar colonization mission, he would likely be in the top 100 Thanks James - If I ever publish a book, I'm putting that quote on the back! On Mon, Jul 29, 2013 at 8:38 PM, James Salsman jsals...@gmail.com wrote: I know I've been critical of Zack Exley for technical reasons over the past year, but I think very highly of him as a person. If I was recruiting colonists for an interstellar colonization mission, he would likely be in the top 100 based on his accomplishments, orientation, drive, and social skills alone. But even if he weren't, his new project is outstandingly spectacular on its own merits, and I want to urge everyone reading this in or from the U.S. to sign up and join it: http://www.fivethirtysix.org/ I predict that anyone with even a passing interest in U.S. politics who doesn't follow FiveThirtySix will first regret it, and then end up following it afterwards to prevent further such regret. Also, congratulations to Megan and Lisa! Sincerely, James Salsman ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Zack Exley Chief Revenue Officer Wikimedia Foundation ___ Wikimedia-l mailing list 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] Wikimedia Italia starts discussion with OSM Italian community to become an OSMF chapter
Dear all, Wikimedia Italia has been in touch for some time with some representatives of the Italian community of OpenStreetMap. The OSM community in Italy is very numerous (see this data[1] for a rough figure) and has a long history, so they were wondering since some time to create a local chapter of the OpenStreetMap Foundation[2] (OSMF) in Italy. Local OSM chapters are similar to Wikimedia Chapters, to the point that the idea and the draft[3] of chapters agreement for chapters and OSMF is taken from Wikimedia Chapters agreement. The idea of creating a local chapter for OSM in Italy has been around for several months, but the community has not yet taken the big step, then some members of this community proposed to join forces with us, given our greater experience as association. Further, being deladdicted/del dedicated to free knowledge some of Wikimedia Italia's members are long-time OSMers. Wikimedia Italia has sponsored OSMit (the Italian OSM conference) in the past and this year we are planning a joint event in October (more info soon) At this stage we are still in the discussion phase. so we would like to hear your feedback. Cristian [1] http://osmstats.altogetherlost.com/index.php?item=countries [2] http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Agreement [3] http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Agreement ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 04:36, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable. The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder* (Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.) This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now. That's what we did last time we switched how templates work (the MW 1.2 - 1.3 transition) . Template syntax conversion bot (or whatever) spidered across the corpus and created a new top revision as needed, IIRC. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
It's interesting how an essentially social question (being welcoming to new people by a Visual editor) turns quickly into a debate on software. Ziko Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl 2013/7/30 James Forrester jforres...@wikimedia.org On 30 July 2013 04:36, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable. The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder* (Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.) This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now. That's what we did last time we switched how templates work (the MW 1.2 - 1.3 transition) . Template syntax conversion bot (or whatever) spidered across the corpus and created a new top revision as needed, IIRC. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list 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 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 15:44, Ziko van Dijk vand...@wmnederland.nl wrote: It's interesting how an essentially social question (being welcoming to new people by a Visual editor) turns quickly into a debate on software. .nl has yet to experience the software in question, and the social issues surrounding it ... - d. ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 08:02, David Gerard dger...@gmail.com wrote: On 30 July 2013 15:44, Ziko van Dijk vand...@wmnederland.nl wrote: It's interesting how an essentially social question (being welcoming to new people by a Visual editor) turns quickly into a debate on software. .nl has yet to experience the software in question, and the social issues surrounding it ... VisualEditor has been enabled as an alpha on nlwiki for testing since May, same as another 15 wikis, actually. But yes, there's a substantive difference between the usage of the software in a small number of knowingly-testing edits by experienced users (who normally want to do relatively-edge cases) and actual real-world usage in exploring the social, design and technical issues. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
Hey Tomasz, this is a good way to start a new thread here, so let me respond. We've done the following with regard to the VE beta so far: - We've overall slowed down the beta rollout schedule; - We've excluded nlwiki from the phase 2 beta rollout; - We've switched dewiki back to opt-in; - We've offered an easy way to hide VisualEditor (it was always possible not to use it). We've also pushed out lots of fixes improvements, including a first round of performance improvements, a better (still not awesome) citations dialog, improvements to the template dialog, etc. If we have to globally go back to opt-in for a while, or some middle-ground (instant opt-out, or advertised beta) we'll do that too. We'd prefer not to, because having developers quickly see the impact of their changes at scale, positive and negative, is essential to making the product better quickly. The steady stream of feedback has been invaluable, and I think the changelog of the last few weeks demonstrates that beyond all doubt. We see very few roundtripping errors. We do see incidents of problematic edits that are unique to a visual editing environment (e.g. backspace-deleting an infobox vs. having to select delete all the markup representing it; reduced precision in applying formatting to content due to mouse selection). Some of those we can help reduce, some of them are inherent and we'll likely have to accept as a cost of introducing a new editor. And we do see the much-discussed issues with complex templates where the question isn't really who is at fault but what the right long term solution is. There are quite a few ugly bugs (it's a beta), but most of those aren't that hard to squash. It'll take longer to make really big gains in performance, though -- that's a genuinely hard problem. We don't think going back into opt-in mode is in the interests of advancing Wikimedia's mission -- maintaining VE as the edit button while making it trivial to edit source forces us to really stay at a high pace of continuous improvement that meets user needs. Nothing constrains choice and imposes urgency like reality. Our preference is therefore to work with the community to stay in continuous improvement mode. If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Mon, Jul 29, 2013 at 11:18 PM, Marc A. Pelletier m...@uberbox.org wrote:
On 07/29/2013 11:10 PM, Risker wrote:
which are used daily on hundreds of pages,
and they serve a very important function.
Yeah, but they are duct tape over weaknesses/flaws in wikimarkup, not a
valuable feature.
Templates such as {{hat}} and {{hab}} don't exist so much because of
weaknesses in wikimarkup as because passing the content as a parameter
would rapidly exceed the Template argument size limit, and possibly
other parser limits. Any solution to this problem would have to take
that into account, unless the vaguely mentioned new parser doesn't
have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than
{{hidden|text= with }} 2000 lines further down in the text. Although I
suppose the comeback to that is that people using VE don't see such
things.
This revolves back to the difficulty in trying to
pretend a talk page in wikimarkup is a discussion medium and doing
forum kind of things with it.
Not entirely. Templates such as {{hidden begin}} and {{hidden end}}
are used to hide long lists in a way that Flow is unlikely to
satisfactorily support. While HTML markup for multi-column lists is
trivial enough to enter directly in a page, people still like to use
templates such as {{div col}} / {{div col end}}. And it's not long ago
that {{col begin}} / {{col end}} were required to give a (hacky)
cross-browser multi-column layout. Nor does this address the
succession box templates mentioned above.
___
Wikimedia-l mailing list
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 have the courage to sit down and talk about VisualEditor
On 30 July 2013 17:03, Erik Moeller e...@wikimedia.org wrote: If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year. de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) - d. ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
On 30 July 2013 14:13, David Gerard dger...@gmail.com wrote: On 30 July 2013 17:03, Erik Moeller e...@wikimedia.org wrote: If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year. de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) Just noting in passing: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC Risker ___ Wikimedia-l mailing list 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] Questions for the WMF Board of Trustees?
Hi Robert, This is a great question. Would you mind adding it to the wiki so we don't lose track of it? Short answer, not speaking for the board, bearing in mind that I missed the past year of board discussions: The board doesn't chose what technology to use but we do have end goals in mind: first and foremost making the wikis easier to edit (for everyone), and also better supporting non-desktop computer technologies (e.g. mobile). We've also had some philosophical discussions about the direction of the internet, and the web slowly turning less hands-on, with people's experiences online siloed into a few big sites -- and what that means for our projects which depend on the experience of saying yes, I can edit this thing. How do we make the projects attractive to new editors growing up in a facebook world? So I think we've certainly discussed the experience question in various ways, though not to the extent of sitting down with look feel/UI charts or anything specific. I think the board's role is to keep doing this, and also to help determine and approve additional specific strategic goals for tech, including for instance supporting community editing initiatives (like the wiki loves monuments app), accurately and beautifully supporting all language communities, etc. You are right that UI and rollouts will be significant for the WMF, the board the editing community for many months to come :) -- phoebe On Mon, Jul 29, 2013 at 12:29 PM, Robert Rohde raro...@gmail.com wrote: Phoebe, I am wondering if you (or another board member) would elaborate a little on how you see the Board's role when it comes to the evolving technical development of WMF projects? WMF has articulated a medium- to long-term vision for Mediawiki that builds on projects like VisualEditor, Flow, Echo (notifications), Parsoid, etc. While I don't expect the Board to be in the business of choosing what technology to use, the WMF vision does seem to speak heavily to future changes in what the experience of editing Wikipedia (and other projects) will be like. More visual and mouse based, etc. Is that something the Board ever involves itself in? Given current plans, it seems likely that questions surrounding changes in user experience and the deployment of new technology will be among the most significant issues for the editor community. -Robert Rohde On Sun, Jul 28, 2013 at 8:31 PM, phoebe ayers phoebe.w...@gmail.com wrote: Hi all, Every year at Wikimania the Wikimedia Foundation Board of Trustees hosts a panel where they take questions from the audience on the work of the WMF and the Board. In past years the board has also taken questions via IRC. This year we'd also like to provide the opportunity to leave questions on a wiki page ahead of time: http://wikimania2013.wikimedia.org/wiki/WMF_Board_Q%26A While there is only time to answer a few questions during the session itself, hopefully this will be a good way of getting questions from attendees as well as from those who can't make it. The board will also take questions from the audience at Wikimania, as time permits. Remember the Board doesn't deal directly with work on or problems on the projects, and does not have a direct hand in how the WMF operates day-to-day. Rather, the board thinks about the big picture, and gives direction on strategy for the WMF. You can find out more about what the board does (and does not do) here: http://wikimediafoundation.org/wiki/Board_of_Trustees and http://meta.wikimedia.org/wiki/Board_handbook best, phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikimedia-l mailing list 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote: de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) [Speaking personally, not for the VE team in any way.] Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating. This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way. In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to. To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it. Steven ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
Templates such as {{hat}} and {{hab}} don't exist so much because of
weaknesses in wikimarkup as because passing the content as a parameter
would rapidly exceed the Template argument size limit, and possibly
other parser limits. Any solution to this problem would have to take
that into account, unless the vaguely mentioned new parser doesn't
have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than
{{hidden|text= with }} 2000 lines further down in the text. Although I
suppose the comeback to that is that people using VE don't see such
things.
From an editing perspective, it seems what's wanted here is a way to
mark regions of text, and then to specify what processing is done on
this region. As you note, {{foo|giant parameter consisting of the whole
region}} is one way to do that, but currently doesn't work technically,
and looks a bit weird syntactically. Perhaps some kind of
region-definition could be a first-class supported feature?
-Mark
___
Wikimedia-l mailing list
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 have the courage to sit down and talk about VisualEditor
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote: de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) [Speaking personally, not for the VE team in any way.] Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating. This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way. In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to. To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it. Steven Let me confess, I hate all new things. I hate the constantly changing complicated wiki markup and I hate the new editor, cause I don't know how to work it even if it would be simpler if I were starting from scratch. The point was to design an editor that would be better for casual and new editors; I have nothing whatever to add from my own experience because I can't duplicate from my experience that of a casual or new editor. Fred ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass
On 30 July 2013 13:58, Mark delir...@hackish.org wrote:
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
Templates such as {{hat}} and {{hab}} don't exist so much because of
weaknesses in wikimarkup as because passing the content as a parameter
would rapidly exceed the Template argument size limit, and possibly
other parser limits. Any solution to this problem would have to take
that into account, unless the vaguely mentioned new parser doesn't
have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than
{{hidden|text= with }} 2000 lines further down in the text. Although I
suppose the comeback to that is that people using VE don't see such
things.
From an editing perspective, it seems what's wanted here is a way to mark
regions of text, and then to specify what processing is done on this
region. As you note, {{foo|giant parameter consisting of the whole region}}
is one way to do that, but currently doesn't work technically, and looks a
bit weird syntactically. Perhaps some kind of region-definition could be a
first-class supported feature?
That'd be great, yes (and really easy to do using Parsoid's DOM) - we
could do annotations, comments, content collapsing, etc. - but I can't see
how it would work with wikitext in a way that would leave it
sanely-editable for users. I'm not sure we want to start building features
that only for work VisualEditor users at this point.
J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.
jforres...@wikimedia.org | @jdforrester
___
Wikimedia-l mailing list
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 have the courage to sit down and talk about VisualEditor
On 30 July 2013 21:47, Steven Walling steven.wall...@gmail.com wrote: Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and OK - so why were those people listened to on de:wp? What happened there that they convinced you? - d. ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
Dear Steven, I think I understand what you mean, and I am concerned about a certain conservatism among the editors, too. Some editors complain all the time anyway. But when 87% reject such a software feature I suppose they cannot be all wrong (by the way, I am one of this huge majority). There are two groups among the rejectors: Those who object a VE in general, and those who are eager to have one but have experienced major problems using it (I am one of them). One of my compatriots has expressed it as I feel it: we often see beta phase software, and sometimes after the beta phase there has never been a final version. But those beta versions usually work well. This is different to the VE version we have experienced. I do appreciate Erik's explanations from above, see that the Foundation does notice what happens, and I agree that the existing community should not have an absolute veto power with regard to the potential community of the future. I do have the impression that people were used as guinea pigs who did not ask for being that. :-) Kind regards Ziko Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl 2013/7/30 Steven Walling steven.wall...@gmail.com On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote: de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) [Speaking personally, not for the VE team in any way.] Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating. This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way. In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to. To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it. Steven ___ Wikimedia-l mailing list 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 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 have the courage to sit down and talk about VisualEditor
On 30 July 2013 22:27, David Gerard dger...@gmail.com wrote: On 30 July 2013 21:47, Steven Walling steven.wall...@gmail.com wrote: Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and OK - so why were those people listened to on de:wp? What happened there that they convinced you? And I would remind you - I've been an ardent advocate of the absolute necessity for a Visual Editor for Wikipedia for the past few years. My qualms are not with change, but this particular instance and the serious problems on many levels the project of its implementation has manifested. It's possible the present project is recoverable into something usable, but it's really not going to just happen. - d. ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
On Tue, Jul 30, 2013 at 2:27 PM, David Gerard dger...@gmail.com wrote: OK - so why were those people listened to on de:wp? What happened there that they convinced you? If you're replying to me... this is why I said I wasn't speaking for the VE team. I didn't make that call. :) Steven ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass
On Tue, Jul 30, 2013 at 2:23 PM, James Forrester
jforres...@wikimedia.org wrote:
That'd be great, yes (and really easy to do using Parsoid's DOM) - we
could do annotations, comments, content collapsing, etc. - but I can't see
how it would work with wikitext in a way that would leave it
sanely-editable for users. I'm not sure we want to start building features
that only for work VisualEditor users at this point.
Which, for the record, is one of our biggest challenges if we want to
be tied to the idea of markup based editing for all eternity. The more
metadata we want to tie to specific aspects of the markup (e.g.
authorship annotations, comments, regions, etc.) the more we really
run into the limitations of easy markup-based editing.
This is already the case for some of our features, like the
translation extension, which makes it possible to mark up parts of the
document as being in need of translation. So you end up with markup
like this:
{| class=wikitable
|-
! translate!--T:21--
Revenue/translate
!style=text-align:right| translate!--T:22--
$50,559,430/translate
|-
| '''translate!--T:23--
Expenses:/translate''' ||
|-
| translate!--T:24--
Engineering Group/translate
|style=text-align:right| translate!--T:25--
$13,523,471/translate
|-
| translate!--T:26--
Fundraiser Group/translate
|style=text-align:right| translate!--T:27--
$3,265,731/translate
etc.
At the very least, as visual editing becomes more powerful, markup
editing likely will become even more cumbersome when dealing with a
lot of this kind of complexity. I also doubt that features like
realtime collaboration will be supportable in the markup mode. That's
why our goal is to really build a visual editor that appeals to
advanced users as well as new ones (which is why we've wanted it to be
so visible to advanced users). We've still got a long way to go in
that regard, of course.
That doesn't mean, however, that we're comfortable just inheriting
wikitext paradigms into the visual editing experience in order to win
over advanced users early. We do have to say no to some
requirements, and one of the asks which we will definitely not
implement is parsing wikitext in VisualEditor to offer the equivalent
functionality. That way lies madness.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
___
Wikimedia-l mailing list
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 have the courage to sit down and talk about VisualEditor
It is absolutely true that the power users can't directly speak for the new users or anons. That said, it would be unusual (though not impossible) if 85% of one group held an opinion without a large fraction of other related communities also sharing that view. If the WMF or someone else wants to commission a study of anon and new users opinions, that would definitely be interesting to see. Personally, I think VE is probably still too immature to be spending a lot of money asking people about it. (In other words, many of the problems and missing features are pretty obvious and we don't need to query large numbers of people to hear about things we already know.) Once it is a bit more stable and the low hanging fruit have been addressed, it could be quite instructive to get some user interaction studies on how people think it could be made better. We also might be able to get some useful data by further A/B testing. For example, if VE is disabled, then assigning some anons to a VE enabled group (perhaps by a cookie) could provide a valuable comparison that we don't presently have. For the moment, the thing we do have is edit counts over time (and similar data). Such data is certainly subject to various confounding influences, but the data we do have for anons and new users isn't exactly exciting. New users are only choosing VE at the 30-40% level for article edits, while anons are at the 20% use level. Not exactly a sign of wild enthusiasm for the new editing platform. By itself, these lowish use numbers are probably enough to conclude that neither group is overwhelmingly excited by VE, though admittedly both numbers are much higher than the 6% usage seen by established users. The number I worry a bit more about is that total anon editing of articles has fallen 9% in the two weeks since introduction (compared to the prior two weeks). During the same time period total editing of articles by registered users rose 2%. Again, correlation is not causation, but if novice editors really liked VE then I would rather have expected total anon editing to increase relative to established users. Even though anons and power user undoubtedly have different needs. I can't help worrying that the bugs, missing features, and sluggish performance that power users complain about might also be discouraging some of the anonymous and new users. If the present state of VE is actually discouraging new editors then that would be a good sign that it isn't yet ready for wide deployment. If I were designing a research program to study VE, I would certainly make getting additional information on anon behaviors a high priority, either by conducting new comparison trials or by finding better ways to tease out patterns in editing trends. -Robert Rohde On Tue, Jul 30, 2013 at 1:47 PM, Steven Walling steven.wall...@gmail.com wrote: On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote: de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) [Speaking personally, not for the VE team in any way.] Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating. This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way. In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to. To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand
[Wikimedia-l] What community initiatives have made an impact on editor engagement?
Thankfully, this change was thought to be temporary. I wonder though how many fundamental violations is removing such an important feature without warning community. As mentioned on Erik's comment above, that was suddenly changed without any warning and preparation. Not providing proper community participation was a mistake that should have been acknowledged already. Sometimes Bugzilla is used in ways that it shouldn't. Community should be aware that CAPTCHA would be removed soon, but it wasn't. Most users were aware only when it was already removed. It is not that you needed permission to do it as it was mistakenly understood by some; it is just a heads up so community could prepare for it. Teles Date: Mon, 29 Jul 2013 23:29:30 -0400 From: z...@mzmcbride.com To: wikimedia-l@lists.wikimedia.org Subject: Re: [Wikimedia-l] What community initiatives have made an impact on editor engagement? Tim Starling wrote: Note that CAPTCHAs have now been re-enabled on the Portuguese Wikipedia. Erik made the decision, in response to on-wiki consensus. I deployed the change just now. https://bugzilla.wikimedia.org/show_bug.cgi?id=49860#c75 Lest there be any confusion or doubt: this is a Bad Thing. We should take this time to explicitly state here (or even re-state here, it's important) that using CAPTCHAs in this way is a fundamental violation of our core principles, particularly site accessibility and openness. As a compromise measure between wiki sovereignty and autonomy and our deeply held values, there's been a temporary reinstatement of the CAPTCHAs on the Portuguese Wikipedia for the remainder of 2013. After December 31, 2013, these CAPTCHAs will be re-disabled. Hopefully no other wiki will feel the need to invoke such a drastic measure ever again. MZMcBride ___ Wikimedia-l mailing list 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 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] Questions for the WMF Board of Trustees?
On Tue, Jul 30, 2013 at 1:24 PM, phoebe ayers phoebe.w...@gmail.com wrote: Hi Robert, This is a great question. Would you mind adding it to the wiki so we don't lose track of it? snip I don't mind adding it, but I'm not sure where you want it to go? Also, should I copy your reply, too? -Robert ___ Wikimedia-l mailing list 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] Staff Images
On 07/12/2013 04:18 AM, Eddy Paine wrote: Dan, A placeholder for people without pictures shouldn't be a problem. Thats common use. And they are all the same so thats a OK thing. The picture of Rory is a picture of Rory. It even says its a mascot and I agree with Erik we need Tux for Engineering. And no, we are not in the 1950's but as a international organisation we should still keep in mind that tattoos aren't accepted world wide. I don't think that should be a requirement. Even clothing choices are not accepted world-wide (in some places, short sleeves and/or showing your hair are considered unacceptable). I see no problem with Brandon's choice to show his tattoo. It might be nice to use a greater depth of field so his face was in focus too, but you can still see it. Matt Flaschen ___ Wikimedia-l mailing list 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] Wiki Project Med Foundation meetup in HK
Hi folks! We're going to have an open Wiki Project Med Foundation (WPMEDF) meeting in Hong Kong over lunch to discuss activities, next steps, and just to see each other in person. WPMEDF works on global medical outreach through Wikipedia. Anyone who's interested in medicine, medical education, public health, research science, or related subjects should just pop in and join us. We'd love to meet you. We'll gather outside the main eating area (wherever that is) and go find a spot to sit down and chat. I hope to see you there! Jake Orlowitz (Ocaasi) *Where: Wikimania, Hong Kong (outside the main eating area)* *When: August 10th, 1pm-2pm (lunchtime)* * * *More info: http://meta.wikimedia.org/wiki/WPMED* ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass
On 7/30/13 11:23 PM, James Forrester wrote:
On 30 July 2013 13:58, Mark delir...@hackish.org wrote:
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
From an editing perspective, it seems what's wanted here is a way to mark
regions of text, and then to specify what processing is done on this
region. As you note, {{foo|giant parameter consisting of the whole region}}
is one way to do that, but currently doesn't work technically, and looks a
bit weird syntactically. Perhaps some kind of region-definition could be a
first-class supported feature?
That'd be great, yes (and really easy to do using Parsoid's DOM) - we
could do annotations, comments, content collapsing, etc. - but I can't see
how it would work with wikitext in a way that would leave it
sanely-editable for users. I'm not sure we want to start building features
that only for work VisualEditor users at this point.
For the wikitext syntax, I'm not sure what the best approach is, but
would some kind of start/end tag syntax work? I had in mind a
region-annotation approach similar to either HTML or LaTeX: region
type=foo/region or that kind of thing. Where foo is the template
(or some other kind of processor) it gets handed off to.
It wouldn't necessarily even have to be much different from what a
{{foo-start}} and {{foo-end}} pair do currently, just the parent
document needs some way of knowing that the pair create a region,
whereas something like regions is currently implicitly created by
unmarked pairs of start/end templates like {{hat}} / {{hab}} that
generate fortuitously matching markup fragments.
-Mark
___
Wikimedia-l mailing list
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] Wikimedia Asia meetup
Hi guys, The annual Wikimedia Asia meetup will take place during Wikimania 2013 in Hong Kong! While there's no definite time yet, we will definitely set off a lunch day for our meeting. We have a lot of things to discuss, so I hope you guys can come in! :) For more information (and to sign up), please go to http://wikimania2013.wikimedia.org/wiki/Wikimedia_Asia_meeting. Regards, Josh JAMES JOSHUA G. LIM Block I1, AB Political Science Major in Global Politics, Minor in Chinese Studies Class of 2013, Ateneo de Manila University Quezon City, Metro Manila, Philippines Trustee (2010-2013), Wikimedia Philippines Member, Ateneo Debate Society Member, The Assembly jamesjoshua...@yahoo.com | +63 (917) 841-5235 Friendster/Facebook/Twitter: akiestar | Wikimedia: Sky Harbor http://akira123323.livejournal.com ___ Wikimedia-l mailing list 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] On the gentrification of Wikipedia, by Superbass
On 07/30/2013 05:23 PM, James Forrester wrote: That'd be great, yes (and really easy to do using Parsoid's DOM) - we could do annotations, comments, content collapsing, etc. - but I can't see how it would work with wikitext in a way that would leave it sanely-editable for users. I'm not sure we want to start building features that only for work VisualEditor users at this point. Surely the solution is as simple as making that a first class syntactic element with a well-defined open and close syntax rather than rely on template trickery. -- Marc ___ Wikimedia-l mailing list 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 have the courage to sit down and talk about VisualEditor
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote: de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.) Hey David, to me, this isn't about power dynamics (who decides, what is the threshold, etc.) but about doing the right thing. It's pretty clear where the en.wp RFC is going - a lot of users aren't comfortable enough with the state of VE to give it the level of visibility it has. Fair enough. I'm not going to dismiss that concern as conservatism about change or any BS like that. There's plenty of that, and there'll be more, but that's not the core issue right now. Where we're coming from is simple. VE needed to get out of the development model with a tiny group of users. It's been absolutely critical to get the level of feedback we've been getting, and to have thousands of users hit every edge case combination of browser/OS/template complexity/editing operation. To get real world reports on various aspects of the experience. To have people in India or Argentina tell us We used VE in a workshop, and here are some of the things that worked and didn't work. And this is not a one-time thing. We can't just work through a mountain of feedback in a waterfall development model and hope that all our assumptions about how to fix this or that complex issue will work out in practice. You can throw cheap user tests at every design, but at the end of the day, you need to go into the real world. Doug Engelbart put it well: The rate at which a person can mature is directly proportional to the embarrassment he can tolerate. This is why our preference is to keep fixing issues every day, as we have been, addressing many of the highest priority real world issues, including performance improvements, reducing nowiki escaping, improving template/citation dialogs, etc. And every time we push out one of those changes, we learn quickly whether it's working or not. The opt-in alpha period wasn't sufficient to give us a large diversity of users. The large-scale beta we're in right now, in spite of not taking anything away from the ability to edit wikitext, is feeling too disruptive for many at this time. What's a reasonable middle ground we could shoot for? In order to continually improve, we really need to build a large pool of users that include IPs, new users, and experienced users. One possibility is to aim for a prominent beta switch that's available to all, similar to what we have on the mobile site. That would be an opportunity to consolidate beta features, and to consistently treat beta as opt-in as is being requested, while increasing the diversity of the pool through increased prominence and recruiting. We'd have some self-selection bias if we don't do better recruiting. Another possibility would be to just maintain a separate, clearly labeled tab for the VisualEditor that gives a prominent beta notice on first-time invocation, with easy permanent dismissal. We may also need to continue to run split A/B tests for different user groups, in order to really get solid quantitative data on experience differences. Other thoughts ideas? All of this is to say - to me this isn't a game with a winner or a loser. We're working on this together to build an awesome editing environment, not to score political points. So let's iterate and find the best way forward together. :) Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
