happy5214 created this task. happy5214 claimed this task. happy5214 added subscribers: Aklapper, happy5214, Legoktm, gerritbot, rmoen, EBernhardson, NiharikaKohli, Capt_Swing, Qgil, jayvdb, Mattflaschen, Xqt, Ricordisamoa, Multichill, Ladsgroup, pywikipedia-bugs. happy5214 added a project: Pywikibot-Flow.
TASK DESCRIPTION The first step in creating a Pywikibot mapping to Flow objects is recognizing what needs to be done and devising a plan. A design must be created to represent the hierarchy of the new Pywikibot classes in relation to the existing code and the relations between these new classes and the Flow API and internal architectural design. This design will take the form of a chart or diagram, perhaps using UML, with the following rules:
# There will be classes representing Flow boards and topics, which will both subclass the existing Page class. # There will be a class representing posts to Flow topics, which will //not// subclass the Page class. # Boards will have descriptions (internally known as "headers"), while each topic will have a title and summary. # The diagram will show the relationships between operations on the Pywikibot objects and Flow API calls where they exist.
This task is due by the start of coding.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Qgil, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Qgil removed a subscriber: Qgil.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Qgil Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
I have created an //early// first draft of a design. The method names in this version reflect their respective API calls, and these will probably //not// be their final names. I must stress that this design will certainly not be the design actually used in the implementation, and that this is just a first step. Much work remains in creating a more natural and Pythonic interface for these API calls and ensuring the use of appropriate data types for fields. I just wanted everyone to see what I've accomplished so far.
XMI format: F164177: Design.xmi https://phabricator.wikimedia.org/F164177
PNG format: F164178: Pywikibot-Flow class diagram.v1.png https://phabricator.wikimedia.org/F164178
PS I know Topic.title should have unicode as its type, but my UML editor has already switched to Python 3 types and I've been too lazy to change them. I also will add the header/description and topic summary fields in the next revision.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Legoktm added a comment.
In https://phabricator.wikimedia.org/T98819#1281446, @happy5214 wrote:
I just wanted everyone to see what I've accomplished so far.
Neat! From a quick look, I think the undo_* functions aren't needed, the bot would just want to fetch the previous content and then update it.
PS I know Topic.title should have unicode as its type, but my UML editor has already switched to Python 3 types and I've been too lazy to change them. I also will add the header/description and topic summary fields in the next revision.
Python 3 is preferred by some of us ;-)
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Legoktm Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Mattflaschen added a comment.
In https://phabricator.wikimedia.org/T98819#1281446, @happy5214 wrote:
Much work remains in creating a more natural and Pythonic interface for these API calls and ensuring the use of appropriate data types for fields.
I agree, this is an area that will need refinement. I need to find the current Pywikibot API documentation so I can see what the current style they use is.
Also, a board can have 0 or more topics (it can exist with only a header), but a topic indeed will always have at least one post.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Mattflaschen added a comment.
Also, you provide no way to go from the topic to the posts, or from posts to parents/replies (latter may not be needed).
Description (header) and summary may deserve to be their own entities, particularly because they are versioned.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Multichill added a comment.
Is any class actually a subclass of Page?
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Multichill Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
In https://phabricator.wikimedia.org/T98819#1284261, @Multichill wrote:
Is any class actually a subclass of Page?
Category, FilePage, and User are Page subclasses. The Wikibase page classes inherit WikibasePage, which in turn inherits BasePage. Looking at it, BasePage might be the better option as a superclass for a FlowPage superclass. I'll have to look into it more.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
Version 2 is up, and a version 3 should be posted by Monday night/Tuesday morning.
F165531: Pywikibot-Flow class diagram.v2.png https://phabricator.wikimedia.org/F165531
I created a new superclass for revision-type objects (TopicSummary, Header, and Post), which I named FlowRevision. It probably isn't necessary due to Python's duck typing, and I'll probably remove it in v3. I also changed method names to remove redundant wording. I redid the inheritance for Topic and Board, making them subclass FlowPage, which inherits from BasePage instead of Page.
This is still very much a WIP. I will still have to research how API calls are made in Pywikibot. It looks like the site objects handle that.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
jayvdb added a comment.
Is topic locking implemented using page protection? Or ... Is page protection used anywhere in the Flow design?
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, jayvdb Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
jayvdb added a comment.
In https://phabricator.wikimedia.org/T98819#1291540, @happy5214 wrote:
Version 2 is up, and a version 3 should be posted by Monday night/Tuesday morning.
F165531: Pywikibot-Flow class diagram.v2.png https://phabricator.wikimedia.org/F165531
I created a new superclass for revision-type objects (TopicSummary, Header, and Post), which I named FlowRevision.
Note we have a Revision class for Page revisions.
It probably isn't necessary due to Python's duck typing, and I'll probably remove it in v3. I also changed method names to remove redundant wording. I redid the inheritance for Topic and Board, making them subclass FlowPage, which inherits from BasePage instead of Page.
Looks good as a foundation.
I will still have to research how API calls are made in Pywikibot. It looks like the site objects handle that.
Yes. Page objects are the API for the script writer , and Site objects contain python-ised equivalent wrapper for each endpoint in the MediaWiki API.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, jayvdb Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Mattflaschen added a comment.
In https://phabricator.wikimedia.org/T98819#1291541, @jayvdb wrote:
Is topic locking implemented using page protection?
No. Lock is a separate moderation state implemented by Flow.
Or ... Is page protection used anywhere in the Flow design?
We respect protection for the topic and board pages. If a board page is protected, you can't do any post on the page, or any topic within it. If a topic page is protected, you can't do any post on that page.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
@Mattflaschen How well do you think ordinary revisions match up with the subclasses of FlowRevision as I've described them. Thinking about it, I can't really find a direct use for FlowRevision, and TopicSummary, etc. will probably have multiple Revision members, one for each revision.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
Version 3 is up.
F166294: Pywikibot-Flow class diagram.v3.png https://phabricator.wikimedia.org/F166294
I ditched the old FlowRevision superclass in favor of another class of the same name, representing individual Flow revisions.
Each attribute with plural name represents a generator method returning the implied objects.
Topic.title is a property returning the contents of the title post, or Topic.root.get(). .get() on the Header, Post, and TopicSummary objects returns the current contents of the object as a Unicode string. .get() on Board and Topic is not yet defined. Come to think of it, do topics and boards even have their own set of revisions?
I plan on making at most two more revisions before my self-imposed deadline for this task, which is Saturday night/Sunday morning. Comments are needed.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
jayvdb added a comment.
regarding 'unicode', it is ok the way it is, however it is important to note that we always use `unicode` (Python 2)/`str` (Python 3) for wiki content, for obvious reasons. We tend to refer to the Python 2 'str' as bytes, as that is the Python 3 name for the equivalent datatype.
Page has a 'text' property, which is the wiki content.
I think `Topic.title` is problematic, as `str.title()` and `BasePage.title()` exist as methods, and do different things (already confusing enough), so adding a attribute (not a method) will make this situation even more confusing, especially as `BasePage.title()` refers to a public unique identifier of the instance (the page title on the wiki).
Which classes have a unique __public__ identifier? Where will this be stored, and how will it be accessed? WikibasePage stores its unique public identifier in an attribute called `id`, and has a method `getID` to obtain that identifier.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, jayvdb Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Mattflaschen added a comment.
In https://phabricator.wikimedia.org/T98819#1295696, @happy5214 wrote:
@Mattflaschen How well do you think 'ordinary', core revisions represented by the Revision class match up with the subclasses of FlowRevision as I've described them? Thinking about it, I can't really find a direct use for FlowRevision, and TopicSummary, etc. will probably have multiple Revision members, one for each revision.
If Revision is the Pywikibot class for core revisions, you will probably not be able to use it at all. Although Flow has full revisioning, and from a user point of view it's similar, it's implemented totally differently (e.g. the revision IDs are UUIDs).
In https://phabricator.wikimedia.org/T98819#1295821, @happy5214 wrote:
Topic.title is a property returning the contents of the title post, or Topic.root.get(). .get() on the Header, Post, and TopicSummary objects returns the current contents of the object as a Unicode string. .get() on Board and Topic is not yet defined. Come to think of it, do topics and boards even have their own set of revisions?
Internally, a topic is represented as a topic title post. That is versioned, can be moderated, and has replies (the topic's top-level posts). Boards are not versioned; the board history just shows history of objects that belong to the board.
In https://phabricator.wikimedia.org/T98819#1300033, @jayvdb wrote:
Which classes have a unique __public__ identifier?
Everything (board, topic, post, revision) is identified by a public UUID.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
happy5214 added a comment.
Version 4 is now available for hopefully prompt review:
F167782: Pywikibot-Flow class diagram.v4.png https://phabricator.wikimedia.org/F167782
I included UUID attributes and accessor methods for FlowPage (inherited by Board and Topic), Post, and FlowRevision. I struggled with how to handle the topic title API calls, first creating a Post subclass for topic roots before just deciding to create methods on Topic to handle editing topic titles. I would have just used the edit process for Post objects (modify the text attribute and call save()), but I figured there's a reason why topic title edits are handled separately in the Flow API.
Topic has two additional convenience methods: get_replies(), which returns root.replies; and get_topic_title(), which returns root.get(). I would not be surprised if all of the "attributes" end up as Python property-style function sets or something similar. getUUID() could just be the getter of a UUID property. The revisions "attribute" on Header, Post, and TopicSummary will probably be implemented by generator methods.
Finally, a question. Are all Flow workflows represented by pages and, if so, could FlowPage be renamed to Workflow?
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214 Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
Mattflaschen added a comment.
It looks good. However, part of the task is to show which Flow API calls will be used.
One of the issues we'll have to deal with (I don't remember if we discussed this before; if not, my bad) is format. Basically:
- Topic titles are always plaintext (no HTML or wiki markup allowed) - Anything else can be in one of three formats, "html" https://www.mediawiki.org/w/api.php?action=flow&format=jsonfm&page=Talk%3AFlow&submodule=view-header&vhformat=html (standard Parsoid), "wikitext" https://www.mediawiki.org/w/api.php?action=flow&format=jsonfm&page=Talk%3AFlow&submodule=view-header&vhformat=wikitext, or "fixed-html" https://www.mediawiki.org/w/api.php?action=flow&format=jsonfm&page=Talk%3AFlow&submodule=view-header&vhformat=fixed-html (only for views)
Not sure how to represent that; maybe a Content object with wikitext and HTML, that sends the correct type for POSTs, and (optionally) could convert behind the scene for GETs (using flow-parsoid-utils).
I like the idea of using properties for uuid, get_replies, etc. (if a field doesn't suffice)
Topic title should probably work the same as posts (with save() button). The API difference can be behind the scenes.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: pywikipedia-bugs, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper
XZise added a subscriber: XZise. XZise added a comment.
Pywikibot itself internally uses wikitext almost entirely. Now I don't know what Flow internally uses, but when we are going to support HTML it should send the HTML to the server which parses it back into wikitext. Otherwise I don't think it's useful to handle HTML. And as wikitext is the probably the basic format, HTML doesn't really provide advantages which would justify supporting it. And pywikibot has support for any API calls so if someone needs HTML for some reason they can build the queries themselves.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, XZise Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
Ricordisamoa added a comment.
Pywikibot should be able to interface with wikitext-only Flow instances.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Ricordisamoa Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
Mattflaschen added a comment.
In https://phabricator.wikimedia.org/T98819#1307343, @XZise wrote:
Pywikibot itself internally uses wikitext almost entirely. Now I don't know what Flow internally uses, but when we are going to support HTML it should send the HTML to the server which parses it back into wikitext.
Flow internally uses Parsoid HTML on the WMF setup (which we also use locally); the version storing wikitext internally is not actively used by developers (though Jenkins uses it). Sending HTML to the server is fine for the Parsoid/store HTML setup. Sending either wikitext or HTML to the server is supported when Flow is using Parsoid.
In https://phabricator.wikimedia.org/T98819#1310295, @Ricordisamoa wrote:
Pywikibot should be able to interface with wikitext-only Flow instances.
Maybe, if we don't drop Parsoid support. However, I don't consider this a hard requirement for the summer GSOC.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
Ricordisamoa added a comment.
In https://phabricator.wikimedia.org/T98819#1314112, @Mattflaschen wrote:
In https://phabricator.wikimedia.org/T98819#1310295, @Ricordisamoa wrote:
Pywikibot should be able to interface with wikitext-only Flow instances.
Maybe, if we don't drop Parsoid support.
Why do you keep insisting?
I don't consider this a hard requirement for the summer GSOC.
If the mapping is well designed, it shouldn't be a problem to support wikitext, now or later.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Ricordisamoa Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
jayvdb added a comment.
Given that pywikibot is heavily designed around using wikitext , and all existing 'add notice to talk page' in scripts is using wikitext, I think this project has a higher chance of avoiding bikeshedding and -2's in code review if it focuses on implementing (only) wikitext support first.
We know what property and methods look like for wikitext, and how they should behave in corner cases. Also script writers are mostly going to prefer to interact with wikitext, as that is what they are most comfortable with. We need to make their transition from Discussion wikitext pages to 'Flow things' as simple as possible.
The design should still emcompass html support, and should put an implementation for it up for review. Semantics around two different/alternative content formats is going to be one of the interesting problems to solve.
In https://phabricator.wikimedia.org/T98819#1314112, @Mattflaschen wrote:
In https://phabricator.wikimedia.org/T98819#1310295, @Ricordisamoa wrote:
Pywikibot should be able to interface with wikitext-only Flow instances.
Maybe, if we don't drop Parsoid support. However, I don't consider this a hard requirement for the summer GSOC.
Is there a phab task about dropping Parsoid support?
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, jayvdb Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
Mattflaschen added a comment.
In https://phabricator.wikimedia.org/T98819#1314439, @jayvdb wrote:
Is there a phab task about dropping Parsoid support?
Sorry for the typo. I meant to write "drop non-Parsoid support". Parsoid is currently the best-supported Flow setup.
It's T88908: Drop support for non-Parsoid configuration https://phabricator.wikimedia.org/T88908. That task resolution is not really final. It only reflects the short-term view.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, Mattflaschen Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
jayvdb added a comment.
Thanks for clarifying.
Recapping, in our last meeting we agreed that the Flow support in Pywikibot would focus on implementing wikitext, with html support as a nice to have that can be a subsequent patch.
TASK DETAIL https://phabricator.wikimedia.org/T98819
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: happy5214, jayvdb Cc: XZise, Ladsgroup, Multichill, Ricordisamoa, Xqt, Mattflaschen, jayvdb, Capt_Swing, NiharikaKohli, EBernhardson, rmoen, gerritbot, Legoktm, happy5214, Aklapper, pywikipedia-bugs
pywikipedia-bugs@lists.wikimedia.org