Draft.js Meeting Notes - 9/7

Attendees

• Claudio (Facebook, data center tools team in Dublin)
• Flarnie (Facebook, long-time maintainer who is transitioning away)
• Julian (Maintainer of https://github.com/draft-js-plugins)
• Marco (Facebook, Workplace team in London)
• Nivedita (Facebook, Internal Tools team)
• Yuze (Twitter, leading the Draft.js integration for Twitter)

Project Updates

Tree Data implementation (Nivedita)

• The current block list model is ill-suited for tables, layouts & other complex behaviours.
• Tables are important for some FB-internal tools & tree data is the best way to implement these.
• Bulk of this work was implemented by Mitermayer & Flarnie; Nivedita is currently implementing a few missing pieces & getting it ready to test on FB internal tools.
• No plans at the moment to migrate other FB usages to the tree data model and/or deprecate the current data model.

Twitter (Yuze)

• They have forked Draft and made some incremental changes.
• React & Draft are being used in the new version of the website.
• They are planning to contribute some issues & PRs back to Draft related to their work.
• They had earlier planned to work on making mobile support more resilient but it is not currently on their near-term roadmap.

Discussion

What are the biggest pain points around working with Draft.js today?

The main issue is that it is hard to contribute (get your PR addressed/issue fixed) & lack of response / timeliness makes potential contributors reluctant to submit PRs.

• There is no clear guidance on what it would take for a PR to get reviewed & accepted.
• The two pain points from the FB maintainer side have been:
  • Lack of resources (this is still a side project for everyone rather than a team owning Draft.js, but hopefully with more maintainers now we can contribute a few hours every week between us).
  • Needing to ensure (via a manual process) that external PRs don't break Facebook, which is why we have been very conservative.
• What can help?
  • Clear guidelines on what PRs need to have to get accepted.
  • Better suite of test cases - possibly we can get help from the OS community on this.
  • If possible, a way to expose some way to run part or all of the FB test suite.
  • Codify part or all of the manual test process if possible.
• Action Items (potentially over the next month):
  • Explore some of the existing PRs to evaluate whether or not they can be pulled in.
  • Come up with some better guidelines for PRs & communicate these to the community.
  • Figure out what test cases are missing & seek out the community's help in adding these to the project.

Brainstorm of ways in which we can deal with existing issues & PRs

• Bug bash
• Take a pass at adding tags & labels for issues (such as `good first issue`).
• Create a more active community, which is more involved in fixing issues. Conferences / events / meetups.

Release process

• Flarnie used to do regular releases every few weeks or months, but didn't have as much time over the past few months.
• We wanted to cut 0.11 but there were some breaking changes - getting this shipped is low-pri.
• We could remove the two-way sync into Facebook master to let the open source community contribute without as much friction.
• But it will be really hard to get these back in sync / pull changes in.
• Yuze gains confidence to pull in latest commits into their fork because Facebook is using this continuously.
• We agreed that forking is a bad idea.

Next meeting will be in two weeks.