= Session Themes and Topics=
* Theme: Architecting our code for change and sustainability
* Topic: Parser and Wikitext
=Session Leader=
* Subbu Sastry (@ssastry)
=Facilitator=
* Kate Chapman
=Description=
This session is focused on ensuring we have the technical requirements for the parser understood as we continue the process of unifying the PHP parser and Parsoid. This includes identifying product directions around wikitext that may impact the requirements of the unified parser long-term.
=Questions to answer during this session=
|**Question**|**Significance: Why is this question important? What is blocked by it remaining unanswered? **
|What is the product vision for visual editing and editing on mobile? If edits become majority visual vs source, how does this impact parser design? What other product goals are likely to impact the design of the parser and how will they do that? |If products are heading towards a WYSIWYG experience for the majority of users that makes Wikitext primarily a power tool for a subset of editors. In this case, it makes sense to evaluate the needs of the parser in that light.
|What are the impacts of parser speed on our technical infrastructure (specifically regarding storage)? What is a good goal for speed of the parser? What does it mean to be fast (returning HTML from storage is fast, but does it need to be fast when generating the HTML?)? Should we only be concerned with balanced templates so that we do not have to regenerate a whole page when content changes? |Speed of the parser has been mentioned in several contexts. It isn’t clear what is meant by this. Are engineers concerned with processor load when regenerating pages or are client engineers and PMs concerned with response time? Are we concerned with the worst case or median times? Is this a user concern or an infrastructure concern? Is the parser already fast enough? Unbalanced templates are known to be an issue here as well since they can modify the rest of the page.
|What are the trade offs between unifying the parsers to a Node.js implementation vs a PHP implementation? |Prior to unifying the parser into PHP, we should ensure there are no use cases or reasons to keep the parser in JS like clients parsing in the browser or in apps. Additionally we should make sure any future needs for VE are accounted for before making this move.
|Should wikitext be the canonical storage for content in MediaWiki? What are the trade-offs between storing HTML vs Wikitext? |Does it make sense to store content as Wikitext if we are returning HTML to clients 99% of the time? Storing HTML seems to remove some of the burden off of the parser since we would only need to support converting to Wikitext when a user want to edit in WIkitext.
|Should having a deterministic/repeatable parser be a goal? Is it useful to have a concept of static vs dynamic templates? What are the advantages to doing this? What are the roadblocks to this? (Specifically discuss Wikitext, Templates, Lua modules) |Not having a deterministic parser has been identified as one of the major reasons to store edits for VE on the server. Is being able to guarantee most of the page stays the same actually get us any benefits? We know that dynamic content is possible in templates, but if we close them and contain that logic does it provide benefits?
|Do we want to evolve wikitext? If so, what aspects / shortcomings do we want to target? What are possible solutions for addressing them? What are the considerations we should factor into any such evolution path? |A number of challenges we now face in the parser and in our products are an outgrowth of wikitext and how it is processed. Certain editing, technology, and usability goals might be advanced / enabled by suitably updating wikitext. But, since this directly impacts editor workflows, this needs to be addressed carefully.
= Keep in mind: =
* The questions proposed above are based on a synthesis of input the PC received about the content of the conference. So, even if answers to some questions might be obvious to some of you, the reason they are there is so that they can be explicitly answered, documented, and used to chart roadmaps without have to revisit them over and over again.
=Scribe Instructions=
Please make a copy of the notes worksheet located here to take notes: https://docs.google.com/document/d/1J-wTeelHFGeXw6dO1ywkGr0NfnzG-cUykowc6aSKoWE/edit?usp=sharing
=Facilitator Instructions=
Use this document for reference:https://docs.google.com/document/d/1TiJTl8xahuXVk7FH5H3hFMWWhzO-vLsUgoW8rHLRJm8
= Resources: =
* Session Guide: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_Guide
= Session Structure =
* **Define session scope, clarify desired outcomes, present agenda**
* Discuss Focus Areas
** Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!''
** For each proposition [add etherpad link here]
*** Decides whether there is (mostly) agreement or disagreement and the proposition(s).
*** Decide whether there is more need for discussion on the topic, and how urgent or important that is.
*** Identify any open questions that need answering from others, and from who (product, ops, etc)
*** Decides who will drive the further discussion/decision process (ie: a four month deadline)
* Discuss additional strategy questions [add etherpad link here]. For each question:
** Decide whether it is considered important.
** Discuss who should answer it.
** Decide who will follow up on it.
* **Wrap up**
= Resources: =
* [[ https://www.mediawiki.org/wiki/Parsing/Parser_Unification | Parser Unification ]]
* [[ https://www.mediawiki.org/wiki/Parsing/Notes/Moving_Parsoid_Into_Core | Moving Parsoid to Core ]]
* [[ https://phabricator.wikimedia.org/tag/parsoid-php/ | Parsoid-PHP phabricator board ]]
* {T93715}
* {T112999}
* {T114454}
* {T204375}
* [[ https://www.mediawiki.org/wiki/Parsing/Notes/Wikitext_2.0 | Parsing Team thoughts about wikitext 2.0 ]]
* [[ https://commons.wikimedia.org/wiki/File:Wikitext_2.0.wikimedia.devsummit.2017.pdf | Devsummit 2017 talk by Parsing team members about wikitext 2.0 ]]
----
**Session Leaders** please:
[X] Add more details to this task description.
[] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc).
[] Outline the plan for discussing this topic at the event.
[] Optionally, include what it will //not// try to solve.
[] Update this task with summaries of any pre-event discussions.
[] Include ways for people not attending to be involved in discussions before the event and afterwards.
----
Post-event Summary:
* ...
Action items:
* ...