Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[Robert Rohde]

Some years back I was importing a large number of complex templates to a
wiki that didn't have tidy enabled.  The results were nothing short of
horrendous in a substantial number of cases.  Wiki authors will generally
stop worrying about their code as long as the results look right.  For good
or ill, tidy does a remarkable job of localizing unclosed tags, and often
that is enough to effectively fix the appearance of broken HTML syntax so
it doesn't spill over into other sections.  Without Tidy (or its
equivalent) there will be a lot of template garbage that needs to be
repaired.

The garbage in -> garbage out approach might seem appealing in principle,
but any transition to such a condition is going to dredge up a lot of
malformed HTML code created by wiki editors that we've been hiding for many
years.  If one is going to replace Tidy with something substantially
different in execution, I would suggest that one needs a significant test
suite of complex pages in order to judge how bad the collateral damage is
likely to be, and ideally some set of tools to help editors fix it.

-Robert Rohde

On Thu, Aug 13, 2015 at 7:51 AM, Brian Wolff  wrote:

> On 8/12/15, MZMcBride  wrote:
> > Tim Starling wrote:
> >>https://phabricator.wikimedia.org/T89331
> >>
> >>Running the output of the MediaWiki parser through HTML Tidy always
> >>seemed like a nasty hack. The effects on wikitext syntax are arbitrary
> >>and change from version to version. When we upgrade our Linux
> >>distribution, we sometimes see changes in the HTML generated by given
> >>wikitext, which is not ideal.
> >>
> >>[...]
> >>
> >>We can get nearly the same effect in MediaWiki by replacing the Tidy
> >>transformation stage with an HTML 5 parse followed by serialization of
> >>the DOM back to HTML. This would stabilize wikitext syntax and resolve
> >>several important syntax differences compared to Parsoid.
> >
> > Related tasks:
> >
> > * https://phabricator.wikimedia.org/T4542
> > * https://phabricator.wikimedia.org/T56617
> >
> > It's not clear to me which behaviors from Tidy we want to keep. Looking
> at
> > the various bugs that Tidy has caused, it's apparent that there a number
> > of behaviors we want to disable/avoid.
> >
> > My understanding is that Tidy is not responsible for output sanitization
> > and it's not responsible for preprocessing or parsing. MediaWiki handles
> > all of that elsewhere. If Tidy is only needed for mismatched HTML
> > elements, we could possibly catch and disallow or gracefully handle that
> > specific use-case in MediaWiki. What other beneficial behavior of Tidy
> > would we need to replicate?
> >
> > Or could we replace Tidy with nothing? Relying on the principle of
> > "garbage in, garbage out" seems reasonable in some ways. And modern
> > browsers are fairly adept at handling moderately bad HTML.
> >
> > MZMcBride
> >
> >
>
> The main thing tidy does (imo), is ensure that mismatched html fails
> are localized. When somebody makes a mistake, it can cause the entire
> skin to go whacko. We ideally want to have markup mistakes only affect
> the user generated content (and preferably, only around the area where
> the mistake is).
>
> --bawolff
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[Brian Wolff]

On 8/12/15, MZMcBride  wrote:
> Tim Starling wrote:
>>https://phabricator.wikimedia.org/T89331
>>
>>Running the output of the MediaWiki parser through HTML Tidy always
>>seemed like a nasty hack. The effects on wikitext syntax are arbitrary
>>and change from version to version. When we upgrade our Linux
>>distribution, we sometimes see changes in the HTML generated by given
>>wikitext, which is not ideal.
>>
>>[...]
>>
>>We can get nearly the same effect in MediaWiki by replacing the Tidy
>>transformation stage with an HTML 5 parse followed by serialization of
>>the DOM back to HTML. This would stabilize wikitext syntax and resolve
>>several important syntax differences compared to Parsoid.
>
> Related tasks:
>
> * https://phabricator.wikimedia.org/T4542
> * https://phabricator.wikimedia.org/T56617
>
> It's not clear to me which behaviors from Tidy we want to keep. Looking at
> the various bugs that Tidy has caused, it's apparent that there a number
> of behaviors we want to disable/avoid.
>
> My understanding is that Tidy is not responsible for output sanitization
> and it's not responsible for preprocessing or parsing. MediaWiki handles
> all of that elsewhere. If Tidy is only needed for mismatched HTML
> elements, we could possibly catch and disallow or gracefully handle that
> specific use-case in MediaWiki. What other beneficial behavior of Tidy
> would we need to replicate?
>
> Or could we replace Tidy with nothing? Relying on the principle of
> "garbage in, garbage out" seems reasonable in some ways. And modern
> browsers are fairly adept at handling moderately bad HTML.
>
> MZMcBride
>
>

The main thing tidy does (imo), is ensure that mismatched html fails
are localized. When somebody makes a mistake, it can cause the entire
skin to go whacko. We ideally want to have markup mistakes only affect
the user generated content (and preferably, only around the area where
the mistake is).

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[MZMcBride]

Tim Starling wrote:
>https://phabricator.wikimedia.org/T89331
>
>Running the output of the MediaWiki parser through HTML Tidy always
>seemed like a nasty hack. The effects on wikitext syntax are arbitrary
>and change from version to version. When we upgrade our Linux
>distribution, we sometimes see changes in the HTML generated by given
>wikitext, which is not ideal.
>
>[...]
>
>We can get nearly the same effect in MediaWiki by replacing the Tidy
>transformation stage with an HTML 5 parse followed by serialization of
>the DOM back to HTML. This would stabilize wikitext syntax and resolve
>several important syntax differences compared to Parsoid.

Related tasks:

* https://phabricator.wikimedia.org/T4542
* https://phabricator.wikimedia.org/T56617

It's not clear to me which behaviors from Tidy we want to keep. Looking at
the various bugs that Tidy has caused, it's apparent that there a number
of behaviors we want to disable/avoid.

My understanding is that Tidy is not responsible for output sanitization
and it's not responsible for preprocessing or parsing. MediaWiki handles
all of that elsewhere. If Tidy is only needed for mismatched HTML
elements, we could possibly catch and disallow or gracefully handle that
specific use-case in MediaWiki. What other beneficial behavior of Tidy
would we need to replicate?

Or could we replace Tidy with nothing? Relying on the principle of
"garbage in, garbage out" seems reasonable in some ways. And modern
browsers are fairly adept at handling moderately bad HTML.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 12 August 2015 at 23:00, Matthew Flaschen  wrote:

> Enforcement is still to-be-determined.


This does need to be sorted out ahead of time. Here's today's horrible example:

http://kovalc.in/2015/08/12/harassers.html


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Code of conduct

[Matthew Flaschen]

On 08/12/2015 05:13 AM, Brian Wolff wrote:

While you're right we don't have a "binding" policy as of yet, I don't
think this should be conflated with us having no rules.


We do have some social conventions, and sometimes these work, but they 
don't always.


There have been instances (on both Wikimedia projects and other 
projects) where people have explicitly used the lack of a binding policy 
to justify their behavior.  The experience of other projects suggests 
that making the policy binding and specific helps.



As long as I can remember, there has been an informal rule, of
"Comment on the code [or proposal], not the contributor", particularly
on the wikitech-l mailing list. Which certainly falls short of many of
the concerns that this proposal intends to address (Although that line
is included in the proposal), however I just want it to be stated that
we are not starting from a state of total anarchy.


I agree.


*Scope is too vague. This is making some people nervous, especially
commons, who really should not feel affected by this policy at all


This has been addressed.  Commons, Wikipedia, etc. are now clearly excluded.


*Unclear what is "broken". Most answers seem to boil down to some sort
of due diligence concern in case something is happening, or "everyone
is doing it", which is rather unsatisfactory to the people asking the
question. A concise rationale for what we want to accomplish with
this, backed up with citations to other people who've dealt with
similar issues, would perhaps alleviate some concerns.


I've added such a citation.  I would summarize as three reasons:

* We have had concrete violations in the past which this would have 
provided a tool to address.


* It provides clear guidance (the preference is that people behave 
respectfully to begin with).


* It sends a message to potential participants: "We welcome you", and 
backs that with more than empty words.



*Unclear how the policy is going to be enforced (For serious
violations), which engenders questions of if it will be enforced
fairly. The lack of specification in the enforcement section probably
means it will be enforced by the WMF, probably behind closed doors.
Will WMF be biased involving disputes where a staff member is a party.


Enforcement is still to-be-determined.

Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Lightning Talks August 25

[Rachel Farrand]

Hi Pine! I love the idea, so thanks for bringing it up. :)

As I said in the email - it is not mandatory that the talks are tech
related, however the point of these specific lightning talks are to be
mostly tech related. Kevin, Megan and I are all very involved in Wikimedia
Tech and are doing this specifically with the goal of spreading information
about ongoing tech projects. We will probably give priority to tech focused
talks for this series, but any extra space can go to whatever else wants to
participate.
If there is someone else (you!?) or another group who wants to run lighting
with the purpose of a broader range of topics I will be happy and willing
to share our lessons learned from these lightning talks. Keep in mind that
this is only our second round of talks so we still have lots of room to
learn, improve, document and change.

A goal of mine is to start documenting the organization process and lessons
from running these talks. Anything that gets written up will go here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Lightning_Talks
There is already a small amount of info, but not much. Check back for
updates! :)

Hope this helps!

On Wed, Aug 12, 2015 at 11:23 AM, Pine W  wrote:

> Hi, nice idea. I'm just wondering if this concept could be expanded to be
> more explicitly inclusive of other kinds of activities like L&E, education,
> GLAM, Legal, Comms, Research, affiliates, etc. I think that this could
> increase participation.
>
> Pine
> On Aug 12, 2015 10:53 AM, "Rachel Farrand"  wrote:
>
> > We (Kevin Leduc, Megan Nestler and I) will be doing a second run of
> > lightning talks  on August
> > 25. The first round had about 40 people viewing living bother remotely
> and
> > in SF as well as another 45 views after the talks.
> > ~ More logistic details/signups found in the email below ~
> >
> > These lightning talks are meant for anyone working on wikimedia tech and
> > are not limited to WMF engineers. If you would like to do a lightning
> talk
> > on any project you are working on please feel free to sign up. Make sure
> to
> > include contact information (or email it to me) so that we (the lightning
> > talk organizers) can coordinate with you. These lightning talks should be
> > relevant to something related to our movement and will mostly be focused
> on
> > tech related projects however it is not mandatory that they are related
> to
> > tech.
> >
> > These talks will continue every month until there is no longer interest.
> >
> > A youtube stream will be sent out to this list just before the talks
> start
> > so you can follow along, you can ask questions on IRC, and the talks will
> > also be recorded so that you can watch them whenever you like.
> >
> > We will adapt this process as we go to make it as interesting and useful
> to
> > everyone as we can.
> >
> > -- Forwarded message --
> > From: Kevin Leduc 
> > Date: Tue, Aug 11, 2015 at 6:26 PM
> > Subject:
> > To: wmf...@lists.wikimedia.org, Engineering list <
> > engineer...@lists.wikimedia.org>
> > Cc: Rachel Farrand , Megan Neisler <
> > mneis...@wikimedia.org>
> >
> >
> > Hello!
> >
> >
> > The next round of Lightning Talks are in two weeks. This effort will not
> > work without your participation...
> >
> > Lightning Talks are an opportunity for teams @ WMF & in the Community to
> > showcase a Quarterly Goal acheived, significant milestone, release, or
> > anything of significance to the rest of the foundation and the movement
> as
> > a whole. These talks will be open to our communities.
> >
> > Each presentation will be 10 minutes or less, the formal part should be
> not
> > be longer than 5 minutes and the remainder can be used for questions.
> >
> > Too many questions to answer in the allotted time?  No worries, your
> > lightning talk will be a great candidate for a future Tech Talk.
> >
> > Second Round of Lightning Talks:
> >
> > When: Tuesday August 25, 1800 UTC
> > <
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks+-+August&iso=20150825T18&p1=1440&ah=1
> > >,
> > 11am PDT
> >
> > Where: 5th Floor
> >
> > Remotees: On-Air google hangout will be provided just before the meeting
> >
> > IRC: #wikimedia-tech
> >
> > Sign up for a 10 minute slot here:
> > https://www.mediawiki.org/wiki/Lightning_Talks
> >
> > With interest, this meeting will become a monthly event.
> >
> > Thanks!
> > Kevin Leduc, Rachel Farrand, Megan Neisler
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wi

Re: [Wikitech-l] Fwd: Lightning Talks August 25

[Pine W]

Hi, nice idea. I'm just wondering if this concept could be expanded to be
more explicitly inclusive of other kinds of activities like L&E, education,
GLAM, Legal, Comms, Research, affiliates, etc. I think that this could
increase participation.

Pine
On Aug 12, 2015 10:53 AM, "Rachel Farrand"  wrote:

> We (Kevin Leduc, Megan Nestler and I) will be doing a second run of
> lightning talks  on August
> 25. The first round had about 40 people viewing living bother remotely and
> in SF as well as another 45 views after the talks.
> ~ More logistic details/signups found in the email below ~
>
> These lightning talks are meant for anyone working on wikimedia tech and
> are not limited to WMF engineers. If you would like to do a lightning talk
> on any project you are working on please feel free to sign up. Make sure to
> include contact information (or email it to me) so that we (the lightning
> talk organizers) can coordinate with you. These lightning talks should be
> relevant to something related to our movement and will mostly be focused on
> tech related projects however it is not mandatory that they are related to
> tech.
>
> These talks will continue every month until there is no longer interest.
>
> A youtube stream will be sent out to this list just before the talks start
> so you can follow along, you can ask questions on IRC, and the talks will
> also be recorded so that you can watch them whenever you like.
>
> We will adapt this process as we go to make it as interesting and useful to
> everyone as we can.
>
> -- Forwarded message --
> From: Kevin Leduc 
> Date: Tue, Aug 11, 2015 at 6:26 PM
> Subject:
> To: wmf...@lists.wikimedia.org, Engineering list <
> engineer...@lists.wikimedia.org>
> Cc: Rachel Farrand , Megan Neisler <
> mneis...@wikimedia.org>
>
>
> Hello!
>
>
> The next round of Lightning Talks are in two weeks. This effort will not
> work without your participation...
>
> Lightning Talks are an opportunity for teams @ WMF & in the Community to
> showcase a Quarterly Goal acheived, significant milestone, release, or
> anything of significance to the rest of the foundation and the movement as
> a whole. These talks will be open to our communities.
>
> Each presentation will be 10 minutes or less, the formal part should be not
> be longer than 5 minutes and the remainder can be used for questions.
>
> Too many questions to answer in the allotted time?  No worries, your
> lightning talk will be a great candidate for a future Tech Talk.
>
> Second Round of Lightning Talks:
>
> When: Tuesday August 25, 1800 UTC
> <
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks+-+August&iso=20150825T18&p1=1440&ah=1
> >,
> 11am PDT
>
> Where: 5th Floor
>
> Remotees: On-Air google hangout will be provided just before the meeting
>
> IRC: #wikimedia-tech
>
> Sign up for a 10 minute slot here:
> https://www.mediawiki.org/wiki/Lightning_Talks
>
> With interest, this meeting will become a monthly event.
>
> Thanks!
> Kevin Leduc, Rachel Farrand, Megan Neisler
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Lightning Talks August 25

[Rachel Farrand]

We (Kevin Leduc, Megan Nestler and I) will be doing a second run of
lightning talks  on August
25. The first round had about 40 people viewing living bother remotely and
in SF as well as another 45 views after the talks.
~ More logistic details/signups found in the email below ~

These lightning talks are meant for anyone working on wikimedia tech and
are not limited to WMF engineers. If you would like to do a lightning talk
on any project you are working on please feel free to sign up. Make sure to
include contact information (or email it to me) so that we (the lightning
talk organizers) can coordinate with you. These lightning talks should be
relevant to something related to our movement and will mostly be focused on
tech related projects however it is not mandatory that they are related to
tech.

These talks will continue every month until there is no longer interest.

A youtube stream will be sent out to this list just before the talks start
so you can follow along, you can ask questions on IRC, and the talks will
also be recorded so that you can watch them whenever you like.

We will adapt this process as we go to make it as interesting and useful to
everyone as we can.

-- Forwarded message --
From: Kevin Leduc 
Date: Tue, Aug 11, 2015 at 6:26 PM
Subject:
To: wmf...@lists.wikimedia.org, Engineering list <
engineer...@lists.wikimedia.org>
Cc: Rachel Farrand , Megan Neisler <
mneis...@wikimedia.org>


Hello!


The next round of Lightning Talks are in two weeks. This effort will not
work without your participation...

Lightning Talks are an opportunity for teams @ WMF & in the Community to
showcase a Quarterly Goal acheived, significant milestone, release, or
anything of significance to the rest of the foundation and the movement as
a whole. These talks will be open to our communities.

Each presentation will be 10 minutes or less, the formal part should be not
be longer than 5 minutes and the remainder can be used for questions.

Too many questions to answer in the allotted time?  No worries, your
lightning talk will be a great candidate for a future Tech Talk.

Second Round of Lightning Talks:

When: Tuesday August 25, 1800 UTC
,
11am PDT

Where: 5th Floor

Remotees: On-Air google hangout will be provided just before the meeting

IRC: #wikimedia-tech

Sign up for a 10 minute slot here:
https://www.mediawiki.org/wiki/Lightning_Talks

With interest, this meeting will become a monthly event.

Thanks!
Kevin Leduc, Rachel Farrand, Megan Neisler
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Content WG: Templating, Page Components & editing

[Bryan Davis]

On Tue, Aug 11, 2015 at 6:12 PM, Gabriel Wicke  wrote:
> TL;DR: Join us to discuss Templates, Page Components & editing on Thu, 13
> August, 12:45 – 14:00 PDT [0].
>
> Please join us at:
>
> Thu, 13 August, 12:45 – 14:00 PDT [0]
>
> by joining the BlueJeans conference call [1],
> on IRC, in #wikimedia-meeting, or
> in Room 37 in the WMF office.
>
> [1]: https://bluejeans.com/2061103652, via phone +14087407256, meeting id

To access the conference without installing the BlueJeans browser
plugin, join using the open WebRTC protocol [2] via the URL
.

[2]: http://www.webrtc.org/

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Content WG: Templating, Page Components & editing

[Subramanya Sastry]

On 08/12/2015 09:33 AM, Brad Jorsch (Anomie) wrote:
On Tue, Aug 11, 2015 at 7:12 PM, Gabriel Wicke > wrote:


TL;DR: Join us to discuss Templates, Page Components & editing on
Thu, 13 August, 12:45 – 14:00 PDT [0].


 I can't, so I'll just comment here.

including a talk by C.Scott at Wikimania [4]


Looking at the slide deck, it's not terribly clear to me what's going 
on through much of it. If you're only referring to the "alternatives 
to templates" section (slides 39-50) it's good, but much of the rest 
isn't so much.


If you are able to look past the WATs (a lot of language implementations 
have those .. and in a few years, maybe someone will make a Parsoid WAT 
talk .. all par for the course), I think it was meant to present some of 
the known problems with wikitext (which you seemed to agree with) and 
use that as a jumping off point to talk about solutions to that  
mostly as a survey of all the ideas that have been floating around, not 
so much as: this is how we should do things. So, yes, some will prove to 
be unviable, etc.


But, it is meant as a conversation starter where we have all the pieces 
in one place rather than going hunting around 10 different wiki pages, 
phab tasks, email threads, whatever.




  * What are the requirements for editing, RL module / metadata
aggregation, dependency tracking?


I don't think anyone will forget it, but keeping the links tables 
(dependency tracking) up to date is important. Flow did forget, for a 
historical example, and the current implementation still leaves a bit 
to be desired. Flow's watchlist and history mechanisms (e.g. 
https://www.mediawiki.org/w/index.php?title=Talk:Web_APIs_hub&action=history 
and how it shows on my watchlist) are rather lacking, too.


When discussing editing: A good WYSIWYG experience is essential, but a 
fully-featured markup editor (that ideally doesn't require directly 
writing JSON blobs or complex RDF structures) would also be very 
useful for many editors.


I agree that the requirement for a good markup editor is not going away. 
So, yes, that is part of the discussion, but this is mostly to highlight 
that markup editing is not the only editing mode that needs support and 
we need to think about what needs fixing so WYSIWYG experience is not 
hobbled.



  * Should we evolve wikitext templates into well-formed page
components?


Probably not. While templates are used to implement "well-formed page 
components" as it seems to be defined here, they're also used for many 
other things.


I think the answer is probably more complex than that.

A lot of template are already, today, behave like well-formed page 
components. However, the parsers don't know that. They have to treat all 
templates with the same conservative brush. Even if we start coming up 
with ways of identifying such templates and enforcing their 
well-formedness, we will have made a fair amount of progress. There are 
various ways to go about that, and those details are something worth 
talking about.


As for the others, I think the page components for infoboxes, navboxes, 
wikidata-widgets, etc. will have taken a big bite out of other kinds of 
templates. And, for the rest, we can talk about leaving current default 
behavior as is and the implications, or talk about other solutions to 
deal with those.


So, maybe a rephrasing of that question would be: "What mechanisms can 
we evolve for using wikitext templates as well-formed page components?" 
which can be a good stepping stone forward without having to solve 
everything at once.


Subbu.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Content WG: Templating, Page Components & editing

[Brad Jorsch (Anomie)]

On Tue, Aug 11, 2015 at 7:12 PM, Gabriel Wicke  wrote:

> TL;DR: Join us to discuss Templates, Page Components & editing on Thu, 13
> August, 12:45 – 14:00 PDT [0].
>

 I can't, so I'll just comment here.

including a talk by C.Scott at Wikimania [4]
>

Looking at the slide deck, it's not terribly clear to me what's going on
through much of it. If you're only referring to the "alternatives to
templates" section (slides 39-50) it's good, but much of the rest isn't so
much.

The first part repeatedly harps on T14974 being stupid. Which I don't think
anyone disagrees with, but hysterical raisins mean it's not simple to just
revert anymore. We need to at least identify what now is depending on that
behavior (xkcd 1172 ).

Then complains about the fact thatthere isn't any general-purpose "escape
template argument" mechanism. True, although overdone in the slide deck.

And then gets into weird attempted abuse of some {{echo}} template in the
context of tables. WAT?

Then it goes back to the escaping issue by proposing a heredoc syntax for
template arguments. Although that as a general concept has its advantages,
it also has disadvantages. Enwiki even has some templates like this, see
{{archive top}}/{{archive bottom}} for just one example.

And then it non-sequiturs into a screenshot of JavaScript code. WAT? Maybe
it's trying to propose a version of Scribunto-with-JS over
Scribunto-with-Lua, ignoring the reasons JS was rejected in favor of Lua
during Scribunto's planning and development.

Then it proposes looping and StringFunctions-like parserfunctions that were
rejected years ago to avoid wikitext becoming even more confusing. WAT?

And JSON blobs embedded in page wikitext are presented as a good idea. WAT?

Also, slides 60-62 seem wrong. The first was probably trying to get at the
fact that {{#tag:ref|barbat}} puts the "bat" reference before
"bar" instead of after, but it misses and the next few go off in some
completely other direction.


>
>- Can we find satisfactory general abstractions for page components
>(well-formed content blocks)?
>
>
"Page components" with structure defined by editors and layout controlled
by the skin would let Mobile get rid of a some of the stupid stuff it does
now to try to work around the existing implementations.

But what do you mean by "general"?

   - A page component for infoboxes, and one for navboxes, and so on? Sure.
   - A generic "page component" thing that can be used for infoboxes,
   navboxes, and so on? Probably not well, although I'd be happy to be proven
   wrong. You'd probably wind up with effectively templates + per-template
   styling + someone actually writing good @media blocks for mobile vs desktop.



>
>- What are the requirements for editing, RL module / metadata
>aggregation, dependency tracking?
>
>
I don't think anyone will forget it, but keeping the links tables (dependency
tracking) up to date is important. Flow did forget, for a historical
example, and the current implementation still leaves a bit to be desired.
Flow's watchlist and history mechanisms (e.g.
https://www.mediawiki.org/w/index.php?title=Talk:Web_APIs_hub&action=history
and how it shows on my watchlist) are rather lacking, too.

When discussing editing: A good WYSIWYG experience is essential, but a
fully-featured markup editor (that ideally doesn't require directly writing
JSON blobs or complex RDF structures) would also be very useful for many
editors.


>
>- Should we evolve wikitext templates into well-formed page components?
>
>
Probably not. While templates are used to implement "well-formed page
components" as it seems to be defined here, they're also used for many
other things.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Code of conduct

[Brian Wolff]

On 8/10/15, Matthew Flaschen  wrote:
> On 08/10/2015 07:10 PM, MZMcBride wrote:
>> I'm not really sure what you're talking about here. We already have:
>
> As you know, none of those are binding policies that apply to all
> Wikimedia technical spaces.
>
>> * https://wikimediafoundation.org/wiki/Friendly_space_policy
>
> This only applies to in-person events.
>
>> * https://meta.wikimedia.org/wiki/Don%27t_be_a_dick [*]
>
> This is more or less reasonable, but it's not even a guideline.  It's
> just an essay,
>
>> * https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>
> This does not apply to the vast majority of Wikimedia technical spaces,
> and does not have the same (or particularly similar) content.
>
>> * https://wikimediafoundation.org/wiki/Code_of_conduct_policy
>
> This is only binding on staff and board members, not the whole
> community.  It's also not specific enough about both what is problematic
> behavior and how we solve it.
>
> Matt Flaschen
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

While you're right we don't have a "binding" policy as of yet, I don't
think this should be conflated with us having no rules.

As long as I can remember, there has been an informal rule, of
"Comment on the code [or proposal], not the contributor", particularly
on the wikitech-l mailing list. Which certainly falls short of many of
the concerns that this proposal intends to address (Although that line
is included in the proposal), however I just want it to be stated that
we are not starting from a state of total anarchy.

After reflecting on the proposed policy a little bit, and various
comments I've read, here's how I feel:

Broadly speaking:

*Scope is too vague. This is making some people nervous, especially
commons, who really should not feel affected by this policy at all
*Unclear what is "broken". Most answers seem to boil down to some sort
of due diligence concern in case something is happening, or "everyone
is doing it", which is rather unsatisfactory to the people asking the
question. A concise rationale for what we want to accomplish with
this, backed up with citations to other people who've dealt with
similar issues, would perhaps alleviate some concerns.
**People who are hindered by the status quo, don't feel comfortable
coming forward with their experience. Which is 100% understandable,
but nonetheless makes it difficult to judge the appropriateness of the
policy.
*Unclear how the policy is going to be enforced (For serious
violations), which engenders questions of if it will be enforced
fairly. The lack of specification in the enforcement section probably
means it will be enforced by the WMF, probably behind closed doors.
Will WMF be biased involving disputes where a staff member is a party.


--
bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l