Re: [Wikitech-l] 2016W23 ArchCom RFC meeting (2016-06-08)

[Cyken Zeraux]

It will be a step forward for the framework for a modern Tidy solution that
properly implements HTML5 support.

On Mon, Jun 6, 2016 at 6:01 PM, Rob Lanphier  wrote:

> Hi everyone,
>
> This week's ArchCom-RFC meeting is about T89331 ("Replace Tidy in MW
> parser with HTML 5 parse/reserialize"). Information about the
> goings-on of ArchCom continues to exist on the ArchCom Status page:
> 
>
> ...and also copied below for your convenience.
>
> My understanding is that the authors feel pretty good about the
> implementation, and are looking for help figuring out how to implement
> a successful migration.
>
> Other handy links and information:
> This week's meeting: 
> RFC for this week's meeting: 
> Subject of the RFC: Replace Tidy in MW parser with HTML 5 parse/reserialize
> Location: #wikimedia-office IRC channel
> Time: 2016-06-08 Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)
>
> I'm looking forward to chatting with you there!
>
> Rob
>
>
>
> 
> Source of [[mw:Architecture_committee/Status]], where "phab:" links
> are pointers to https://phabricator.wikimedia.org
>
>
> This page provides status update for [[Requests for
> comment|ArchCom-RFCs]], with an emphasis on ArchCom team member.  As
> of this writing on 2016-04-29, this update is an experiment discussed
> [[Topic:T2zctt083izvx07l|weekly ArchCom update discussion on the
> "ArchCom/Team practices" talk page]].
>
> = Recent RFC meetings =
> * ArchCom Planning meeting 2016W22: 2016-06-01: [[Phab:E197]] (E156/9)
> ** Notes: [[Architecture committee/2016-06-01]]
> * ArchCom-RFC office hour 2016W22: 2016-06-01: [[Phab:E198]] (E66/37)
> ** Security discussion, including:
> *** CSP - [[Phab:T135963|T135963]]
>
> = Upcoming RFC meetings =
> *ArchCom Planning meeting 2016W23: 2016-06-08: [[Phab:E202]] (E156/10)
> **Notes: [[Architecture committee/2016-06-08]]
> *ArchCom-RFC office hour 2016W23: 2016-06-08: [[Phab:E203]] (E66/38)
> ** [[Phab:T89331|T89331 Replace Tidy in MW parser with HTML 5
> parse/reserialize]]
>
> = Entering Final Comment Period =
> * None.
>
> = Recently Approved =
> * none
>
>  RFC inbox 
> * [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
> ** Inbox zero on 2016-06-11.
>
> = Shepherd status =
> * Brion
> ** Multi-content revisions (T107595) is interesting
> * Daniel
> ** Software Quality working group?
> ** Working on Multi Content Rev Spec with Brion
> ** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
> Sites and WikiMap]]: checking in with Adam
> ** T89733 (approved, with Stas driving implementation)
> * Gabriel
> ** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
> [[Phab:T132597|T132597]] (no longer an RFC)
> * Roan
> ** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
> need to start the second part, but the recent comments have me
> confused. I'll need to talk to Timo and figure out what the subject of
> part two should be.
> * RobLa
> ** Starting to use [[Phab:Z425]] as asynchronous ArchCom-RFC channel,
> testing Conpherence use for means of piloting ArchCom working groups.
> We may still have more separate triage discussions, but I'm waiting to
> get feedback on [[phab:T135674|T135674]].
> ** Working with [[User:DPatrick (WMF)|DPatrick]] on [[Wikimedia
> Security Team]] issues in an attempt to be useful there.
> * Tim
> ** [[Phab:T89331|T89331 (Replace Tidy in MW parser with HTML 5
> parse/reserialize)]] - should meet to discuss migration rather than
> implementation plan
> ** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
> wikitext]]: (Update?)
> * Timo
> ** Section anchors - will update T18691
> ** CSP - [[Phab:T135963|T135963]] - Will shepherd
> ** Local storage abstraction [[Phab:T121646|T121646]] working with
> Fundraising on this to move cookies into local storage; not an RFC
> yet, but may become one.
>
> = No activity in the last two weeks =
> * T122942 [[phab:T122942|RFC: Support language variants in the
> RESTBase]] (Gabriel)
> * T39902 [[phab:T39902|RFC: Implement rendering of redlinks in
> Parsoid]] (no shepherd)
> * T18691 [[phab:T18691|RFC: Section headings should have a clickable
> anchor]] (Timo)
> * T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
> * T123753 [[phab:T123753|Establish retrospective reports for Security
> and Performance incidents]] (RobLa)
> * T122825 [[phab:T122825|Service ownership and minimum maintenance
> requirements]] (Gabriel)
> * T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
> * T124504 [[phab:T124504|Transition WikiDev '16 working areas into
> working groups]] (RobLa)
> * T66214 [[phab:T66214|Use content hash based image / thumb URLs &
> define an official thumb API]] (Brion)
> * T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
> * T128351 [[phab:T128351|RFC: Notifications in core]] 

[Wikitech-l] 2016W23 ArchCom RFC meeting (2016-06-08)

[Rob Lanphier]

Hi everyone,

This week's ArchCom-RFC meeting is about T89331 ("Replace Tidy in MW
parser with HTML 5 parse/reserialize"). Information about the
goings-on of ArchCom continues to exist on the ArchCom Status page:


...and also copied below for your convenience.

My understanding is that the authors feel pretty good about the
implementation, and are looking for help figuring out how to implement
a successful migration.

Other handy links and information:
This week's meeting: 
RFC for this week's meeting: 
Subject of the RFC: Replace Tidy in MW parser with HTML 5 parse/reserialize
Location: #wikimedia-office IRC channel
Time: 2016-06-08 Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)

I'm looking forward to chatting with you there!

Rob




Source of [[mw:Architecture_committee/Status]], where "phab:" links
are pointers to https://phabricator.wikimedia.org


This page provides status update for [[Requests for
comment|ArchCom-RFCs]], with an emphasis on ArchCom team member.  As
of this writing on 2016-04-29, this update is an experiment discussed
[[Topic:T2zctt083izvx07l|weekly ArchCom update discussion on the
"ArchCom/Team practices" talk page]].

= Recent RFC meetings =
* ArchCom Planning meeting 2016W22: 2016-06-01: [[Phab:E197]] (E156/9)
** Notes: [[Architecture committee/2016-06-01]]
* ArchCom-RFC office hour 2016W22: 2016-06-01: [[Phab:E198]] (E66/37)
** Security discussion, including:
*** CSP - [[Phab:T135963|T135963]]

= Upcoming RFC meetings =
*ArchCom Planning meeting 2016W23: 2016-06-08: [[Phab:E202]] (E156/10)
**Notes: [[Architecture committee/2016-06-08]]
*ArchCom-RFC office hour 2016W23: 2016-06-08: [[Phab:E203]] (E66/38)
** [[Phab:T89331|T89331 Replace Tidy in MW parser with HTML 5
parse/reserialize]]

= Entering Final Comment Period =
* None.

= Recently Approved =
* none

 RFC inbox 
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** Inbox zero on 2016-06-11.

= Shepherd status =
* Brion
** Multi-content revisions (T107595) is interesting
* Daniel
** Software Quality working group?
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: checking in with Adam
** T89733 (approved, with Stas driving implementation)
* Gabriel
** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
[[Phab:T132597|T132597]] (no longer an RFC)
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Starting to use [[Phab:Z425]] as asynchronous ArchCom-RFC channel,
testing Conpherence use for means of piloting ArchCom working groups.
We may still have more separate triage discussions, but I'm waiting to
get feedback on [[phab:T135674|T135674]].
** Working with [[User:DPatrick (WMF)|DPatrick]] on [[Wikimedia
Security Team]] issues in an attempt to be useful there.
* Tim
** [[Phab:T89331|T89331 (Replace Tidy in MW parser with HTML 5
parse/reserialize)]] - should meet to discuss migration rather than
implementation plan
** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
* Timo
** Section anchors - will update T18691
** CSP - [[Phab:T135963|T135963]] - Will shepherd
** Local storage abstraction [[Phab:T121646|T121646]] working with
Fundraising on this to move cookies into local storage; not an RFC
yet, but may become one.

= No activity in the last two weeks =
* T122942 [[phab:T122942|RFC: Support language variants in the
RESTBase]] (Gabriel)
* T39902 [[phab:T39902|RFC: Implement rendering of redlinks in
Parsoid]] (no shepherd)
* T18691 [[phab:T18691|RFC: Section headings should have a clickable
anchor]] (Timo)
* T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
* T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]] (RobLa)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
* T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] (RobLa)
* T66214 [[phab:T66214|Use content hash based image / thumb URLs &
define an official thumb API]] (Brion)
* T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
* T128351 [[phab:T128351|RFC: Notifications in core]] (Brion)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T54807 [[phab:T54807|Identify and remove legacy preferences from
MediaWiki core]] (no shepherd)
* T88596 [[phab:T88596|Improving extension management]] (Daniel)

= Useful Phab links =
* [[phab:maniphest/query/xc.j4DEYcjwu/#R|Query for shepherd assignments]]
* 

[Wikitech-l] Wikipedia.org portal update - browser language detection and new A/B test

[Deborah Tankersley]

Hello,

The Discovery team recently updated the wikipedia.org portal page to detect
what the visitor's browser's preferred language(s) are and then arrange the
language links around the globe to match those language preferences.

Earlier this year, we ran a successful A/B test

that proved promoting our visitor's preferred languages resulted in
increased visibility and interest into these projects. Also, the display of
'*The Free Encyclopedia*' phrase is now localized to the visitor's first
preferred browser language. If there isn't a translation available, the
phrase will be displayed in English (view a screenshot
)
as it currently is today.

Additionally, a new A/B test

will kick
off this week to determine if the listing of languages by article count can
be displayed in a more modern and streamlined way without decreasing usage
of the links. Our goal is to promote easy scrolling through the long list
of languages by article count, but in a dropdown format while also
providing greater discovery of the sister wiki project links.

More information on past and future work can be found on the wiki page
 as well as the sprint
 and backlog
 boards. We're
always interested in receiving constructive feedback from the community: if
you have a question or comment, please start a discussion on the talk page
.


Cheers,

Deb
--
Deb Tankersley
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Enabling shared tabular data pages

[Yuri Astrakhan]

Rob, thanks for your offer to help! Always welcome :)

By discussion and positive feedback I meant Facebook and Commons comments,
and a very old and elaborate phab ticket discussion:
* https://phabricator.wikimedia.org/T120452
*
https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Tabular_data_storage_for_Commons.21
* https://www.facebook.com/groups/wikipediaweekly/permalink/997545366959961/

I do not think this feature will immediately have a huge uptake. It will
simplify graph design, as it will be possible to store data outside of the
graph. It will also allow data from tables and lists to be moved into
separate wiki pages. The work of moving existing data into these pages
might not be very fast. In short, it will only be accessible from Lua and
graphs, will be less than 2MB each, and will require some technical skills
to edit JSON until better tools are created.


On Mon, Jun 6, 2016 at 9:14 PM, Rob Lanphier  wrote:

> On Mon, Jun 6, 2016 at 6:40 AM, Yuri Astrakhan 
> wrote:
>
> > Daniel, I agree about the data/api versioning. I was mostly talking about
> > features and capabilities. For example, we could spend the next year
> > developing a visual table editor, implement support for unlimited table
> > sizes, provide import/export from other table formats, introduce
> elaborate
> > schema validation, and many other cool features. And after that year
> > realize that users don't need this whole thing at all, or need something
> > similar but very different.  Or we could release one small, well defined,
> > stable subset of that functionality, get feedback, and move forward.
> >
>
> Hi Yuri,
>
> I think one thing that would be helpful for me (and I suspect many people
> who want to help) is some more specifics about this statement from your
> original email: "We have had some good feedback for the new shared tabular
> data feature, and we are getting ready to deploy it in production."  Which
> "we" are you referring to, and by "getting ready to deploy it in
> production", does that mean it's about to be usable where someone could
> upload gigabytes of production data in this format Commons by the end of
> the week?  Is there a more measured plan published somewhere?
>
> This all sounds very cool, but also an area where we could accidentally
> accrue a crushing load of technical debt without fully realizing it (per
> Daniel's comment).  I'll confess to being ignorant on everything that's
> been going on, and I'm wondering now how desperately I should study your
> documentation to make up for it (and how important it is to drop other work
> to make time for this).
>
> Rob
> ___
> 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] Enabling shared tabular data pages

[Yuri Astrakhan]

Daniel, thanks, inline:

The structure looks sane and future-proof to me, but since it's
> all-in-one-blob,
> it'll be hard to scale it to more than a few ten thousand lines or so. I
> like
> this model, but if you want to go beyond that (DO we want to go beyond
> that?!)
> you will need a different approach, which may be incompatible.
>

We do *eventually* want to go beyond that towards large data. We had this
discussion with Brion, see here:
*  https://phabricator.wikimedia.org/T120452#2224764

I do not think my approach is a blocker for larger datasets, because you
can add simple SQL-like interface capable of reading data from these pages
and from large backend databases. 2MB page limit will prevent page data
from growing too large. Also, larger datasets is a different target, that
we should approach when we are ready.

One thing that should be specified very rigorously from the start are the
> supported data types, along with their exact syntax and semantics. Your
> example
> has string, number, boolean, and localized. So:
>
> * what's the length limit for string?
>
Good question. Do you have a limit for Wikidata labels and other string
values?

> * what's the range and precision of number? Is it the same as for JSON?
>
For now, same as JSON.

> * does boolean only accept JSON primitives, or also strings?
>
true/false only, no strings

> * what language codes are valid for localized? Is language fallback
> applied for
> display?
>
Same rules as for wiki language codes (but without validation against the
actual list). Automatic fallback is already implemented, using Language
class.  If everything else fails, and there is no English, takes random
first (unlike Language which stops at English and fails otherwise).


> You write in your proposal "Hard to define types like Wikidata ID,
> datetime, and
> URL could be stored as a string until we can reuse Wikidata's type system".
> Well, what's keeping you from using it now? DataValue and friends are
> standalone
> composer modules, you can find them on github.

I was told by the Wikidata team at the Jerusalem hackathon that the
Javascript code is too entangled, and I won't be able to reuse it for
non-Wikidata stuff.  I will be very happy to adapt it if possible. Yet, I
do not think this is a requirement for the first release.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Enabling shared tabular data pages

[Daniel Kinzler]

Am 06.06.2016 um 15:40 schrieb Yuri Astrakhan:
> Do you have any thoughts about the proposed data structure?

The structure looks sane and future-proof to me, but since it's all-in-one-blob,
it'll be hard to scale it to more than a few ten thousand lines or so. I like
this model, but if you want to go beyond that (DO we want to go beyond that?!)
you will need a different approach, which may be incompatible.

One thing that should be specified very rigorously from the start are the
supported data types, along with their exact syntax and semantics. Your example
has string, number, boolean, and localized. So:

* what's the length limit for string?
* what's the range and precision of number? Is it the same as for JSON?
* does boolean only accept JSON primitives, or also strings?
* what language codes are valid for localized? Is language fallback applied for
display?

Not answering these questions now may lead to having data that can later no
longer be properly interpreted. If you get into quantities with precision or
date, this becomes a lot more fun. In that case, you would want to re-use the
DataValues module(s) that Wikidata uses.

You write in your proposal "Hard to define types like Wikidata ID, datetime, and
URL could be stored as a string until we can reuse Wikidata's type system".
Well, what's keeping you from using it now? DataValue and friends are standalone
composer modules, you can find them on github.

-- daniel

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

Re: [Wikitech-l] Enabling shared tabular data pages

[Rob Lanphier]

On Mon, Jun 6, 2016 at 6:40 AM, Yuri Astrakhan 
wrote:

> Daniel, I agree about the data/api versioning. I was mostly talking about
> features and capabilities. For example, we could spend the next year
> developing a visual table editor, implement support for unlimited table
> sizes, provide import/export from other table formats, introduce elaborate
> schema validation, and many other cool features. And after that year
> realize that users don't need this whole thing at all, or need something
> similar but very different.  Or we could release one small, well defined,
> stable subset of that functionality, get feedback, and move forward.
>

Hi Yuri,

I think one thing that would be helpful for me (and I suspect many people
who want to help) is some more specifics about this statement from your
original email: "We have had some good feedback for the new shared tabular
data feature, and we are getting ready to deploy it in production."  Which
"we" are you referring to, and by "getting ready to deploy it in
production", does that mean it's about to be usable where someone could
upload gigabytes of production data in this format Commons by the end of
the week?  Is there a more measured plan published somewhere?

This all sounds very cool, but also an area where we could accidentally
accrue a crushing load of technical debt without fully realizing it (per
Daniel's comment).  I'll confess to being ignorant on everything that's
been going on, and I'm wondering now how desperately I should study your
documentation to make up for it (and how important it is to drop other work
to make time for this).

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

Re: [Wikitech-l] [Engineering] [ANNOUNCEMENT] MathML/SVG as the default rendering mode on all projects

[Michael Holloway]

Awesome work, Physikerwelt and all involved!

On Mon, Jun 6, 2016 at 9:46 AM, Marko Obrovac 
wrote:

> Hello,
>
> On Tuesday, May 31 we have deployed a change to the production cluster
> that sets MathML with SVG fall-back as the default rendering mode for
> mathematical formulae for all Wikimedia projects~[1]. This change brings
> scaleable and selectable formulae to the whole Wikimedia community, not
> just logged-in users, thus opening new perspectives for better rendering,
> accessibility, search, equation sharing, font and unicode support, styling,
> line breaking…
>
> We are very excited about this feature seeing the light of day, not only
> because of the visible improved experience for our reader and editors, but
> also because this project has been carried out in collaboration with the
> community. In particular, this achievement would not have been possible
> without Moritz Schubotz (aka User:Physikerwelt), who has been the lead
> developer of Mathoid, the rendering service responsible for producing the
> MathML and SVG code that the end-users see on the web-site.
>
> You can read more about this awesome feature on the MathML Association’s
> web-site~[2].
>
> Best,
> The WMF Services Team
>
> [1] https://phabricator.wikimedia.org/T131177
> [2] http://mathml-association.org/announcement/2016/05/31/wikipedia.html
>
>
> --
> Marko Obrovac, PhD
> Senior Services Engineer
> Wikimedia Foundation
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [ANNOUNCEMENT] MathML/SVG as the default rendering mode on all projects

[Marko Obrovac]

Hello,

On Tuesday, May 31 we have deployed a change to the production cluster that
sets MathML with SVG fall-back as the default rendering mode for
mathematical formulae for all Wikimedia projects~[1]. This change brings
scaleable and selectable formulae to the whole Wikimedia community, not
just logged-in users, thus opening new perspectives for better rendering,
accessibility, search, equation sharing, font and unicode support, styling,
line breaking…

We are very excited about this feature seeing the light of day, not only
because of the visible improved experience for our reader and editors, but
also because this project has been carried out in collaboration with the
community. In particular, this achievement would not have been possible
without Moritz Schubotz (aka User:Physikerwelt), who has been the lead
developer of Mathoid, the rendering service responsible for producing the
MathML and SVG code that the end-users see on the web-site.

You can read more about this awesome feature on the MathML Association’s
web-site~[2].

Best,
The WMF Services Team

[1] https://phabricator.wikimedia.org/T131177
[2] http://mathml-association.org/announcement/2016/05/31/wikipedia.html


-- 
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Enabling shared tabular data pages

[Yuri Astrakhan]

Daniel, I agree about the data/api versioning. I was mostly talking about
features and capabilities. For example, we could spend the next year
developing a visual table editor, implement support for unlimited table
sizes, provide import/export from other table formats, introduce elaborate
schema validation, and many other cool features. And after that year
realize that users don't need this whole thing at all, or need something
similar but very different.  Or we could release one small, well defined,
stable subset of that functionality, get feedback, and move forward.

Do you have any thoughts about the proposed data structure?

On Mon, Jun 6, 2016 at 4:09 PM, Daniel Kinzler 
wrote:

> Am 04.06.2016 um 18:47 schrieb Yuri Astrakhan:
> > In line with the "release early, release often", we will not have any
> > elaborate data editing interface beyond the raw JSON code editor for the
> > first release.
>
> A word of caution about this strategy: this is great for user facing
> things, but
> it really sucks if you are creating artifacts, such as page revisions. You
> will
> have to stay compatible with your very first data format, and the second,
> and
> the third, etc, forever. Similarly, once you have an ecosystem of tools
> that
> rely on your API and data model, changing it becomes rather troublesome.
>
> So, for anything that is supposed to offer a stable API, or creates
> persistent
> data, "release early, release often" is not a good strategy in my
> experience. A
> lot of pain lies this way. Remember: wikitext syntax was once a "let's
> just make
> it work, we will fix it later" hack...
>
> -- daniel
>
> ___
> 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] Enabling shared tabular data pages

[Daniel Kinzler]

Am 04.06.2016 um 18:47 schrieb Yuri Astrakhan:
> In line with the "release early, release often", we will not have any
> elaborate data editing interface beyond the raw JSON code editor for the
> first release. 

A word of caution about this strategy: this is great for user facing things, but
it really sucks if you are creating artifacts, such as page revisions. You will
have to stay compatible with your very first data format, and the second, and
the third, etc, forever. Similarly, once you have an ecosystem of tools that
rely on your API and data model, changing it becomes rather troublesome.

So, for anything that is supposed to offer a stable API, or creates persistent
data, "release early, release often" is not a good strategy in my experience. A
lot of pain lies this way. Remember: wikitext syntax was once a "let's just make
it work, we will fix it later" hack...

-- daniel

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