On Wed, Jul 24, 2013 at 2:06 AM, Subramanya Sastry
<ssastry(a)wikimedia.org> wrote:
Hi John and Risker,
First off, I do want to once again clarify that my intention in the previous
post was not to claim that VE/Parsoid is perfect. It was more that we've
fixed sufficient bugs at this point that the most significant "bugs" (bugs,
not missing features) that need fixing (and are being fixed) are those that
have to do with usability tweaks.
How do you know that? Have you performed automated tests on all
Wikipedia content? Or are you waiting for users to find these bugs?
My intention in that post was also not
one to put some distance between us and the complaints, just to clarify that
we are fixing things as fast as we can and it can be seen in the recent
changes stream.
John: specific answers to the edit diffs you highlighted in your post. I
acknowledge your intention to make sure we dont make false claims about
VE/Parsoid's usability. Thanks for taking the time for digging them up.
My answers below are made with an intention of figuring out what the issues
are so they can be fixed where they need to be.
On 07/23/2013 02:50 AM, John Vandenberg wrote:
On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry
<ssastry(a)wikimedia.org> wrote:
On 07/22/2013 10:44 PM, Tim Starling wrote:
Round-trip bugs, and bugs which cause a given wikitext input to give
different HTML in Parsoid compared to MW, should have been detected
during automated testing, prior to beta deployment. I don't know why
we need users to report them.
500+ edits are being done per hour using Visual Editor [1] (less at this
time given that it is way past midnight -- I have seen about 700/hour at
times). I did go and click on over 100 links and examined the diffs. I
did
that twice in the last hour. I am happy to report clean diffs on all
edits
I checked both times.
I did run into a couple of nowiki-insertions which
is, strictly speaking not erroneous and based on user input, but is more
a
usability issue.
What is a dirty diff? One that inserts junk unexpectedly, unrelated
to the user's input?
That is correct. Strictly speaking, yes, any changes to the wikitext markup
that arose from what the user didn't change.
The broken table injection bugs are still
happening.
https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=144…
If the parser isnt going to be fixed quickly to ignore tables it
doesnt understand, we need to find the templates and pages with these
broken tables - preferably using SQL and heuristics and fix them. The
same needs to be done for all the other wikis, otherwise they are
going to have the same problems happening randomly, causing lots of
grief.
This maybe related to this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51217 and I have a tentative
fix for it as of y'day.
Fixes are of course appreciated. The pace of bugfixes is not the problem ...
VE and Parsoid devs have put in a lot and lot of
effort to recognize broken
wikitext source, fix it or isolate it,
My point was that you dont appear to be doing analysis of how of all
Wikipedia content is broken; at least I dont see a public document
listing which templates and pages are causing the parser problems, so
the communities on each Wikipedia can fix them ahead of deployment.
I believe there is bug about automated testing of the parser against
existing pages, which would identify problems.
I scanned the Spanish 'visualeditor' tag's 50 recentchanges earlier
and found a dirty diff, which I believe hasnt been raised in bugzilla
yet.
https://bugzilla.wikimedia.org/show_bug.cgi?id=51909
50 VE edits on eswp is more than one day of recentchanges. Most of
the top 10 wikis have roughly the same level of testing going on.
That should be a concern. The number of VE edits is about to increase
on another nine Wikipedias, with very little real impact analysis
having been done. That is a shame, because the enwp deployment has
provided us with a list of problems which will impact those wikis if
they are using the same syntax, be it weird or broken or otherwise
troublesome.
and protect it across edits, and
roundtrip it back in original form to prevent corruption. I think we have
been largely successful but we still have more cases to go that are being
exposed here which we will fix. But, occasionally, these kind of errors do
show up -- and we ask for your patience as we fix these. Once again, this
is not a claim to perfection, but a claim that this is not a significant
source of corrupt edits. But, yes even a 0.1% error rate does mean a big
number in the absolute when thousands of pages are being edited -- and we
will continue to pare this down.
Is 0.1% a real data point, or a stab in the dark? Because I found two
in 100 on enwp; Robert found at least one in 200 on enwp; and I found
1 in 50 on eswp.
You are correct, but this is not a dirty diff. I dont want to claim this is
an user error entirely -- but a combination of user and software error.
fwiw, I wasnt claiming these or the ones that followed were dirty
diffs; these are other problems which the software is a contributor
to, *other* than the nowiki cases we know so well.
Here is three
edits to try to add a section header and a sentence,
with a wikilink in the section header.
(In the process they added other junk into the page, probably
unintentionally.)
https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history…
What is the problem here exactly? (that is a question, not a challenge).
The user might have entered those newlines as well.
The VE UI is confusing, and did many silly things during those edits.
The user had to resort to editing in source editor to clean it up.
Step through the diffs.
--
John Vandenberg