Add meeting notes from 9/7

meta/meeting-notes/2018-09-07-meeting.md

@@ -0,0 +1,59 @@
+# 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.