[Wikimedia-l] Open letter to the new CTO

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Wikimedia-l] Open letter to the new CTO

Rogol Domedonfors
Dear Dr Coleman

Congratulations on your appointment. May I offer some suggestions for
things you might like to pay attention to now tas you embark on your new
job. I suggest that engagement with the volunteer community, especially at
a strategic and early stage in your decision making will be vital, as will
driving that engagement down to the medium-term goals and activities. Of
course by engagement I mean an intelligent and intelligible two-way
discussion in which all sides participate in a spirit of freedom,
frankness, fairness and constructive dialogue. You may wish to develop a
more coherent and consistent set of portals or other specific and
well-resourced vehicles for that engagement for the medium term, aligned
with the WMF planning and delivery processes, sufficiently well-resourced
to make a different to the coherence and effectivness of your operations. I
further venture to suggest that you may wish to foster a more rigorous
culture of planning and effective delivery to plans than has been universal
in the past, coupled with transparancy and accountability in the full view
of the community who are their ultimate customers.

There are some specific strategic objectives where that engagement has been
absent and where that absence has been hampering effectiveness. It would be
a good idea to get a clear concise and measurable set of obectives around
the areas of Visual Editor, Wikitext, Parsoid, Flow, Workflow and
Discovery. I believe it is also essential that having done so, you publish
them to and involve the Community in an effective way in testing the
direction and delivery of your plans in those areas. Currently there is not
the community buy-in that you need to make these plans effective.  You will
probably want to specifically understand, clarify and stabilise the
proposal around editor and parser unification, which have been mentioned in
public, without detals being made available – there is a considerable
impact on the workflow of the existing base of volunteer content
contributors.

I will allow myslf the freedom to give you my views on the current
performance of your staff and the progress on some of these projects, which
of course you will complement or contradict as you pursue your
investigations. Those views are not positive, and will probably not be
welcome to you or to your staff. They are nonetheless a genuine view of
those projects as seen by a member of the community keen to be a critical
and constructive observer -- and they are summarised by the four words
 *under-ambitious,
under-resourced, under-managed and under-performing*. The VE/Parsoid/Flow
complex suffers from scope mismatch. As a vehicle for delivering a WYSIWYG
editor and discussion board it is over-complex, while VE and Flow are
under-ambitious. Can these really be regarded as cutting edge in 2016? If
correctly scoped they could and should have been delivered and finalised
long ago, if not brought in from pre-existing open source projects.  The
execution of the VE project has been lacklustre. Such a straightforward
product should have been finished long since, and it was clearly
inadequately resourced and managed. Indeed, it has been explained to me in
patronising terms at least twice that this is the way Agile looks. No, this
is the way a badly managed project looks. The current culture appears not
to pritorise such issues as timeliness and grip. Finally, Workflow has
already failed. In the absence of resources to undertake the required
research into the huge complexity of work flows within the projects,
whatever is designed will be designed in ignorance, and hence simply can
not succeed. Ever. It is already a waste of time.

In terms of the wider project, the view of an editing and rendering engine
as handling only unidirectional linear text fails to capture even the
richness of current projects let alone future knowledge modalities, such as
complex text (hieroglyphics, chemistry, mathematics, music),
higher-dimensional data (genomic, proteomic, 3D printing), data in time
(audio, video), interactive, computational, ... all of which could and
should have been scoped out by your innovation work.  Please consider how
you can develop a vibrant and ambitious innovation initiative, actively led
and managed, and in partnership with world-class organisations involved in
knowledge management, representation and curation.

Having mentioned Agile, let me say that the way it is currently regarded in
the WMF seems to me to be fundamentally misconceived.  The attitude towards
Agile development, as put to me by staff, appears to me to be an excuse for
designing without clear goals or user involvement, and delivery of shoddy
bug-ridden code into production systems for the hapless users to debug.  As
I say, this is not Agile.

So, what can be done? The answer is simple, but requires a change in
culture as much as one of process, and change you will need to drive. You
must stop your staff thinking of the community as a burden which you have
to support (a position explicitly taken by the previous ED in 2015) or at
best a lumpenproletariat to work at your direction (a position explicitly
taken by the Board Chair in 2014).  Your staff need to engage with users as
equals, not de haut en bas. The community is here to work with you if you
will let it. As CTO you need an open frank constructive and imaginative
dialogue on planning and future direction, termination of currently failed
or failing projects, resourcing of those which are jointly agreed on, and
drive and grip by leaders who are can provide a strong rigorous and
supportive framework that delivers what the community needs.


With best wishes

"Rogol"
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

C. Scott Ananian
I'm going to take the bait and respond in part, to defend the teams and
projects I work with:

On Tue, Nov 8, 2016 at 2:47 PM, Rogol Domedonfors <[hidden email]>
wrote:

> they are summarised by the four words
>  *under-ambitious,
> under-resourced, under-managed and under-performing*. The VE/Parsoid/Flow
> complex suffers from scope mismatch. As a vehicle for delivering a WYSIWYG
> editor and discussion board it is over-complex,


I'll stop here.  I think it is poorly understood in the community how
complex wikitext markup has been allowed to grow over the decades it has
been under development.  There *is no specification for wikitext*.  We have
informal guides which omit most of the interesting corner cases, like, say,
priority between conflicting markup.  Take a look at
http://spec.commonmark.org/ to see what a precise specification for a *much
simpler* markup language would look like.  As you read through the cases in
that spec, consider that if you translated most of the examples into
wikitext, *literally no one knows what the expected output would be*.  The
implementation is too organic, with bits glommed on ad-hoc, and we'd
probably have to run them through the parser to find out what happens:
there is no way for a human to reason about it.

So, yes: VE/Parsoid are very complex (I'll leave Flow for a little further
down, be patient).  Part of this was a learning process: when I joined the
project in 2013 there was a perhaps-naïve sense that we could easily
implement a sort of "cleaned up wikitext" and migrate any markup that
broke.  Over the intervening years (and in response to heated criticism of
Visual Editor when the "cleaned up wikitext" failed to exactly match
editors' expectations), Parsoid has grown and grown, until it has almost as
many barnacles as the core PHP parser.

This is not only a challenge for engineering.  This is a challenge to the
community.  In order to actually achieve simplicity in our parser and
editor we will need to make aggressive changes to our content markup in
order to reverse years (decades) of poorly-understood workarounds to buggy
or underspecified wikitext syntax.  Yes, you can fault WMF management (and
I'll personally take some blame) for not aggressively pushing the community
into this action, but the community in its turn has been strongly resistant
to proposed changes in wikitext, which they characterize as "for the sake
of Visual Editor", not fully realizing the extent to which the obscurity of
the current wikitext syntax imperils the editability, archivability and
future usability of the content we are creating.

We need to tackle this challenge together.  Only when we commit to
aggressively updating the wikitext used in our projects, will we be able to
drop the "unnecessary" complexity of the parser-editor implementation.
There are a number of different proposals for "wikitext 2.0", more than one
of which I expect will be the subject of sessions at the developer summit
this year (
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Handling_wiki_content_beyond_plaintext).
But again: the engineers can't do it alone.  It's not just an engineering
problem.  We *started* with the engineering solution (simple parsoid/VE
with no compatibility barnacles) and had to spend the next three years in
further development because of social/human factors --- namely, every time
that VE or Parsoid "broke" something the solution was to complicate the
parser and editor, not to fix the wikitext.  If we want to scale down
ongoing development, we need to tackle the community side of the larger
issue of wikitext maintenance and migration.

I think you actually agree: you finish your open letter with, "Your staff
need to engage with users as equals, not de haut en bas. The community is
here to work with you if you will let it."  But this goes both ways -- as a
community we need to stop treating our existing content as sacrosanct, and
recognize that the community needs to accept change if they want
engineering to finish projects and move the platform forward.


> while VE and Flow are
> under-ambitious. Can these really be regarded as cutting edge in 2016?


Agreed.  We have collaborative features being rolled out in VE now, but
that just brings us to the state of the art circa 2005/6, when Google Docs
(nee Writely) was written (or ~2009, when AbiWord gained its collaborative
features in version 2.8.0).  Yes, we're late.  But the actual
implementation of a collaborative editor has always been the "easy part"
(see https://www.mediawiki.org/wiki/Extension:TogetherJS for example).  The
hard parts were:

1. Always generating exactly the wikitext a human editor would generate for
a given edit (which varies by projects).

2. Open social collaboration among tens of millions of users on WMF
projects (~30 million on enwiki alone), while respecting privacy and
preventing harassment.

I discussed #1 above.  #2 is still an open problem -- not just for us, but
for the "state of the art".  If you are aware of a similar WMF-scale
collaborative editor, do let me know!  In particular, balancing openness,
privacy, anti-harassment and anti-vandalism is a hard problem.  We are
working on this, but this will also require buy-in from the community.  We
have to embrace, together, a real-time UX for Wikipedia without reflexively
pushing back just because "it's not how editing on Wikipedia used to be".
We probably need to be open to trying things, learning what works and what
doesn't, and then trying other things -- without blaming WMF for the
shortcomings of the first attempt.  This was a proposed topic for the dev
summit, has some proposed sessions as well (
https://phabricator.wikimedia.org/T149661 and
https://phabricator.wikimedia.org/T149663), and I've been leading sessions
at Wikimania on this since 2014 to encourage discussion in the community
(see
https://en.wikipedia.org/w/index.php?title=User:Cscott&action=edit#Wikimedia_Talks_and_Presentations
).

Perhaps this is actually your point: we need the community and engineering
to work together.  We need the community to embrace change, enabling
engineering to implement that change.



> If
> correctly scoped they could and should have been delivered and finalised
> long ago, if not brought in from pre-existing open source projects.


Again, if we just adopted (say) markdown or pure-HTML for our content, we
could have used one of the existing editors.  But instead the community
wanted something which looked just like traditional wikitext.  If there's a
failure in vision there, it cuts both ways.


>  The execution of the VE project has been lacklustre. Such a
> straightforward
> product should have been finished long since, and it was clearly
> inadequately resourced and managed.


Again, there's has been a *lot* of background work to make a project "look"
straightforward.  Inadequately resourced I could agree with -- there was a
WMF reorg under the previous ED that reassigned most of VE's engineers.  It
still doesn't really have enough resources to tackle an aggressive project
like collaborative editing; especially considering that "adequate"
resourcing would probably involve all parts of engineering to develop an
integrated UX for collaboration, not just resources in the editing team.
Calls to cut resources and "finish" VE don't help.

 The current culture appears not
> to pritorise such issues as timeliness and grip.


I'd say that the current culture rewards short-term projects with
immediately realizable and quantifiable goals that are highly likely to be
successful.  That's not a bad thing, per se, but you seem to be arguing for
the adoption of larger scale projects with "vision".  WMF has become scared
of large scale projects after the community rejection of Visual Editor,
Media Viewer, and Flow.  It has interpreted the community's reaction to
these projects as a directive to "think smaller" and concentrate on simple
reactions to user bug reports.

This is what led to VE/Parsoid spending years tweaking the support of
corner case legacy constructs and trying to generate output that looks more
and more like traditional wikitext, instead of "finishing" the project.  If
you want projects to end cleanly, the community has to agree one a point at
which things are "done enough" and that future issues should be
accommodated by content changes or behavior changes, not by endless
refinements to the code.


> Finally, Workflow has
> already failed. In the absence of resources to undertake the required
> research into the huge complexity of work flows within the projects,
> whatever is designed will be designed in ignorance, and hence simply can
> not succeed. Ever. It is already a waste of time.
>

I think you are suggesting that we devote the resources required to
properly understand the workflow problem and adequately solve the problem?

What we are currently doing is actually what you indicate: we have stopped
development on Flow and given up on the general workflow problem, instead
looking at small tools for specific work flows -- like the addition of ORES
scores to various review processes.  We are not currently working on the
general workflow problem.


> In terms of the wider project, the view of an editing and rendering engine
> as handling only unidirectional linear text fails to capture even the
> richness of current projects let alone future knowledge modalities, such as
> complex text (hieroglyphics, chemistry, mathematics, music),
> higher-dimensional data (genomic, proteomic, 3D printing), data in time
> (audio, video), interactive, computational, ... all of which could and
> should have been scoped out by your innovation work.


I'm not sure why you think that VE/Parsoid only supports unidirectional
linear text?  Our RTL support is actually quite robust.  And VE supports
WikiHiero -- see for example
https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet#WikiHiero.
Further extensions are limited mostly by the community's willingness to
write support: the infrastructure to add extensions to Visual Editor and
Parsoid are both present.

I do think we should spend time thinking about non-text content.

Hence
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Handling_wiki_content_beyond_plaintext
, https://phabricator.wikimedia.org/T149554, and
https://phabricator.wikimedia.org/T90914#2759122 for instance.  I think the
general rule of Wikimedia Incubator projects holds -- if the community
generated really compelling content in new media, WMF engineering would be
increasingly motivated to provide tools to support that new media.  It's a
bit of a chicken-and-egg problem.  We tried to envision what "cool content"
might look like at the last Wikimania (see "Integrated video" and
"Integrated VR/panorama" at https://en.wikipedia.org/wiki/User:Cscott/Ideas),
but I think engineering is rightly reluctant to spend a lot of resources
developing these sorts of features w/o content requiring them.

To conclude, I would like to echo your call for increased collaboration
between community and engineering.  But in addition to the "engineering
should build what the community wants" direction, we need to also build the
"community should embrace changes arising from WMF efforts to evolve the
platform" direction.  The necessary balance and interplay between these
factors has been missing, and that has resulted in an engineering
department which is too under-resourced to actually execute a vision for
the future.  And in the absence of a vision for the future, the community
has called for engineering to scale down (further) and "focus".

This is not healthy for the future of the project.
  --scott

--
(http://cscott.net)
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

Pine W
In reply to this post by Rogol Domedonfors
Hi Rogol,

I wish I could comment in depth. The one comment that I will make is that
Katherine's tone toward the community has generally been receptive, and so
far we (meaning WMF, the community, and the affiliates) have not had
large-scale conflicts since she became the interim ED, which I consider a
good thing and I would like to see continue. I have my own wish list for
Katherine, as I think you know. But I also feel we should be grateful that
so far, she seems to be making an effort to cooperate with the wishes of
the community / communities and the wishes of the affiliates in general.

Thanks,
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

rupert THURNER-2
In reply to this post by C. Scott Ananian
On Nov 9, 2016 20:26, "C. Scott Ananian" <[hidden email]> wrote:

>
> I'm going to take the bait and respond in part, to defend the teams and
> projects I work with:
>
> On Tue, Nov 8, 2016 at 2:47 PM, Rogol Domedonfors <[hidden email]>
> wrote:
>
> > they are summarised by the four words
> >  *under-ambitious,
> > under-resourced, under-managed and under-performing*. The
VE/Parsoid/Flow
> > complex suffers from scope mismatch. As a vehicle for delivering a
WYSIWYG
> > editor and discussion board it is over-complex,
>
>
> I'll stop here.  I think it is poorly understood in the community how
> complex wikitext markup has been allowed to grow over the decades it has
> been under development.  There *is no specification for wikitext*.  We
have
> informal guides which omit most of the interesting corner cases, like,
say,
> priority between conflicting markup.  Take a look at
> http://spec.commonmark.org/ to see what a precise specification for a
*much
> simpler* markup language would look like.  As you read through the cases
in
> that spec, consider that if you translated most of the examples into
> wikitext, *literally no one knows what the expected output would be*.  The

To make the long story short I would really love and support any well
specified markup. If it is only for a part of the content and there is a
note on top which syntax the text follows I d love it too.

Rupert
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

Rogol Domedonfors
In reply to this post by Rogol Domedonfors
Thanks to C. Scott Ananian for a response which is more informative than
almost all the other communications I have received on the subject of
planning for the future of the editor and parser software.  It will not
come amiss, I hope, if I pick up a few points for further discussion.

Firstly, my posting was not "bait" nor does it require the teams and
projects to be defended.  It was intended as constructive criticism and as
such I would hope that the people concerned take it in that spirit.
However, I quite understand that no criticism, however well justified or
motivated, is ever entirely welcome.

Secondly, while Scott is a Senior Softwre Engieer in the Parsing team, I
take it that his comments are more a personal point of view than a formal
expression of intention on the part of the Foundation.  If I'm wrong, and
he is speaking with full authority for the Foundation on some or all of the
points he makes, it would be helpful to have that noted explicitly.

Thirdly, let's look at the point "WMF has become scared of large scale
projects after the community rejection of Visual Editor,Media Viewer, and
Flow. It has interpreted the community's reaction to these projects as a
directive to "think smaller" and concentrate on simple reactions to user
bug reports."  That may be the case, but if so it represents a major
category mistake.  The community reaction was against having unwanted and
unworkable changes imposed on them by force majeure without previous
involvement and without consultation, and that is completely and
overwhelmingly obvious from their reaction.  The size of the projects was
never the primary issue.  If the WMF wanted to know, raher than guess, what
the community's view was, and why they reacted as they did, and if it was
genuiney unsure about those points, and especially if it saw itself as
being directed by the community, then it could and should have engaged with
the community to find out what it was that the community did and did not
want.  This did not happen at the time, still does not happen in any way
that can support sensible planning, and very badly needs to happen.  Of the
WMF staff view themselves as have been directed by the community to do or
not do anything over the last couple of years, then you and they need to
kow that this is very much the opposite of the view from the community.

Fourthly, there is the issue of wikitext.  This is not the place to discuss
the technicalities.  The point at issue is that the huge investment by the
community of contributors in extant wikitext, and the major effort and
disruption required to modernise, will have to be balanced against the
benefits of a new system, whatever that might be.  This cannot work unless
there is full, clear and open engagement between WMF developers and the
wider community.  Currently that simply is not happening.  I have
explicitly asked where plans for the future of the editors and the parsr
unification project can be seen, and there has simply been no response.  Do
those plans exist?  If so, where are they, and why are they not being
shared wth the community.  If not, why and how is any work proceeding, and
what process will be used to developt those plans, and in particular, hwow
will the community be involved?  These are not questions of idle curiosity
for one particular user's satisfaction, they issues requiring clear and
public articuation as key components of any successful future staraegy to
avoid the disastrous mistakes of the past.

Fifthly I note that there have been repeated assurances over time that the
content of the databases will continue to be wikitext, and that wikitext
will be directly editable, at least for the foreseeable future.  Those
assurances came from people who oight to know and who appeared to be
speaking on behalf of, and with the authority of the WMF.  The comments
made by Scott do not entirely support those assurances.

Finally I repeat my thanks for what has been one of the more informative
and positive responses I have yet to see in this area.  I note that the
message of much improved engagement between WMF staff and volunteer
community is one that it shared to some considerable extent, and I reagrd
that as a step in the right direction,

"Rogol"
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

C. Scott Ananian
On Sun, Nov 13, 2016 at 5:08 PM, Rogol Domedonfors <[hidden email]>
wrote:

> I have
> explicitly asked where plans for the future of the editors and the parsr
> unification project can be seen, and there has simply been no response.  Do
> those plans exist?  If so, where are they, and why are they not being
> shared wth the community.  If not, why and how is any work proceeding, and
> what process will be used to developt those plans, and in particular, hwow
> will the community be involved?  These are not questions of idle curiosity
> for one particular user's satisfaction, they issues requiring clear and
> public articuation as key components of any successful future staraegy to
> avoid the disastrous mistakes of the past.
>

In the past two years:

https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Handling_wiki_content_beyond_plaintext
(coming up!)
https://www.mediawiki.org/wiki/Parsing
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy/FAQ
https://wikimania2015.wikimedia.org/wiki/Submissions/Templates_are_dead!_Long_live_templates
!
https://wikimania2015.wikimedia.org/wiki/Submissions/Mediawiki_without_wikitext
https://wikimania2015.wikimedia.org/wiki/Submissions/Wikitext_is_broken,_long_live_wikitext_(2.0)

Fifthly I note that there have been repeated assurances over time that the
> content of the databases will continue to be wikitext, and that wikitext
> will be directly editable, at least for the foreseeable future.  Those
> assurances came from people who oight to know and who appeared to be
> speaking on behalf of, and with the authority of the WMF.  The comments
> made by Scott do not entirely support those assurances.
>

The "assurances" are not as black-and-white as you seem to think.  There
are a number of ways to translate on-the-fly between alternative
representations and wikitext, as well as some debate about what "wikitext"
actually is.  If we clean up a seldom-used corner case in the wikitext
specification, is that still "wikitext"?  If we replace wikitext templates
with Scribunto templates is it still "wikitext"?  If we change boldface to
{'' ... ''} instead of triple-quotes, is that still wikitext?  Etc.
Further, see:

https://www.mediawiki.org/wiki/Multi-Content_Revisions

for broader context on the backend changes, which will make it possible to
store multiple equivalent representations of any of our content ("legacy
wikitext", "wikitext 2.0", "HTML", etc), and translate on-the-fly
back-and-forth between them.  We currently do this for Flow, for example,
where the "in database" representation is HTML, even if you are editing it
in "wikitext".  So there are lots of ways to tweak the dials to always
allow "wikitext editing" -- which, indeed, is under no attack.  (Our
archives, however, are currently in quite a perilous state due to the
currently-underspecified nature of "wikitext".)

Multi-Content Revisions has been through a public RFC process:
https://phabricator.wikimedia.org/T107595

Indeed, the short answer to your question about process would be,
"Wikimania", "Developer Summit", and "Architecture Committee" (
https://www.mediawiki.org/wiki/Architecture_committee).  It is rare that
any substantial project at WMF hasn't been through all three of those
public forums, and records of each are posted for the benefit of those who
can't attend.  (Although this year at Esino Lario the public process
determined that the Wikimania attendees didn't actually want to have
parsing- or wikitext-related technical discussions, and so instead I
participated in a public hackathon for offline functionality organized by
the Kiwix community.  I surveyed attendees however and everyone I talked to
indicated that WMF staff was adequately represented and no one reported any
trouble finding staff members to answer questions.)
 --scott, [[User:cscott]]

--
(http://cscott.net)
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Open letter to the new CTO

Sam Klein
I really appreciate the thoughtful detail in this thread.  Thanks, Scott.

Multi-content revisions are a really good idea and the level of public
discussion seemed fitting.

> If we clean up a seldom-used corner case in the wikitext
> specification, is that still "wikitext"?  If we replace wikitext templates
> with Scribunto templates is it still "wikitext"?  If we change boldface to
> {'' ... ''} instead of triple-quotes, is that still wikitext?

Yes ...

> in addition to the "engineering should build what the community wants"
direction,
> we need to also build the "community should embrace changes arising from
WMF
> efforts to evolve the platform" direction.  The necessary balance and
interplay
> between these factors has been missing

Fair enough.


On Mon, Nov 14, 2016 at 5:55 PM, C. Scott Ananian <[hidden email]>
wrote:

> On Sun, Nov 13, 2016 at 5:08 PM, Rogol Domedonfors <[hidden email]>
> wrote:
>
> > I have
> > explicitly asked where plans for the future of the editors and the parsr
> > unification project can be seen, and there has simply been no response.
> Do
> > those plans exist?  If so, where are they, and why are they not being
> > shared wth the community.  If not, why and how is any work proceeding,
> and
> > what process will be used to developt those plans, and in particular,
> hwow
> > will the community be involved?  These are not questions of idle
> curiosity
> > for one particular user's satisfaction, they issues requiring clear and
> > public articuation as key components of any successful future staraegy to
> > avoid the disastrous mistakes of the past.
> >
>
> In the past two years:
>
> https://www.mediawiki.org/wiki/Wikimedia_Developer_
> Summit/2017/Handling_wiki_content_beyond_plaintext
> (coming up!)
> https://www.mediawiki.org/wiki/Parsing
> https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy
> https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy/FAQ
> https://wikimania2015.wikimedia.org/wiki/Submissions/Templates_are_
> dead!_Long_live_templates
> !
> https://wikimania2015.wikimedia.org/wiki/Submissions/Mediawiki_without_
> wikitext
> https://wikimania2015.wikimedia.org/wiki/Submissions/Wikitext_is_
> broken,_long_live_wikitext_(2.0)
>
> Fifthly I note that there have been repeated assurances over time that the
> > content of the databases will continue to be wikitext, and that wikitext
> > will be directly editable, at least for the foreseeable future.  Those
> > assurances came from people who oight to know and who appeared to be
> > speaking on behalf of, and with the authority of the WMF.  The comments
> > made by Scott do not entirely support those assurances.
> >
>
> The "assurances" are not as black-and-white as you seem to think.  There
> are a number of ways to translate on-the-fly between alternative
> representations and wikitext, as well as some debate about what "wikitext"
> actually is.  If we clean up a seldom-used corner case in the wikitext
> specification, is that still "wikitext"?  If we replace wikitext templates
> with Scribunto templates is it still "wikitext"?  If we change boldface to
> {'' ... ''} instead of triple-quotes, is that still wikitext?  Etc.
> Further, see:
>
> https://www.mediawiki.org/wiki/Multi-Content_Revisions
>
> for broader context on the backend changes, which will make it possible to
> store multiple equivalent representations of any of our content ("legacy
> wikitext", "wikitext 2.0", "HTML", etc), and translate on-the-fly
> back-and-forth between them.  We currently do this for Flow, for example,
> where the "in database" representation is HTML, even if you are editing it
> in "wikitext".  So there are lots of ways to tweak the dials to always
> allow "wikitext editing" -- which, indeed, is under no attack.  (Our
> archives, however, are currently in quite a perilous state due to the
> currently-underspecified nature of "wikitext".)
>
> Multi-Content Revisions has been through a public RFC process:
> https://phabricator.wikimedia.org/T107595
>
> Indeed, the short answer to your question about process would be,
> "Wikimania", "Developer Summit", and "Architecture Committee" (
> https://www.mediawiki.org/wiki/Architecture_committee).  It is rare that
> any substantial project at WMF hasn't been through all three of those
> public forums, and records of each are posted for the benefit of those who
> can't attend.  (Although this year at Esino Lario the public process
> determined that the Wikimania attendees didn't actually want to have
> parsing- or wikitext-related technical discussions, and so instead I
> participated in a public hackathon for offline functionality organized by
> the Kiwix community.  I surveyed attendees however and everyone I talked to
> indicated that WMF staff was adequately represented and no one reported any
> trouble finding staff members to answer questions.)
>  --scott, [[User:cscott]]
>
> --
> (http://cscott.net)
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines
> New messages to: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Samuel Klein          @metasj          w:user:sj          +1 617 529 4266
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>