We have JSConf.eu and other WhatTheFest activities happening in Berlin this May. Since that’ll bring a bunch of JavaScripters to our city who usually aren’t there, I guess that’s a good opportunity to hold a third ProseMirror summit.
Our first summit a year and a half ago was a success, in that some of the people in the community met each other, explained use cases, and laid the groundworks for the schema system (ProseMirror was quite young then). Then there was a second summit in New York, which was also very enlightening.
So I’d like to invite everybody to join me May 5th, starting 19:00, for another evening of ProseMirror-related discussion. Points on the agenda will include the 1.0 release (which may fall near that date), community involvement, whichever technical questions I’m stuck on at that time, and you’re welcome to suggest your own points.
Unless a huge crowd shows up, we can hold it at my office (Katzbachstr 34, near S-Bahn station Yorckstraße), but that has only a limited amount of room and chairs, so please RSVP if you want to come, so that we can try to find a bigger space if necessary (and I can notify you if we do). Reply to this thread or email me directly if you’re planning to come.
Everybody is welcome, regardless of experience and familiarity with ProseMirror (though some discussion may of course go over your head if you’re new). We’ll use the Berlin code of conduct as a baseline set of social rules.
I’ve received a bunch of RSVPs, so this is definitely happening. It looks like the group will be smallish, and we’ll be able to use the meeting room at my office, Katzbachstraße 34 on the ground floor.
We were 9 people, and had some good discussion. I didn’t take notes, but I’ll try to summarize the main points.
I’m probably not going to release 1.0 for a while, not because of API stability—the current API is pretty much what I want to release—but because I want to have much better docs in place, so that I can widely announce it without disappointing people. I have a few other things I’m busy with right now, but after those, writing docs and preparing the 1.0 release will be my priority.
Now is a good time to start writing blog posts and such—if you’ve done something cool with project, written a plugin, or figured out a good approach to a complex use case.
Also, when you find something is missing from the docs or dodgy about the website, please file issues, so that I can keep track of the things I should clarify.
I asked about what kind of community involvement people would like to see. We agreed to set up an [RFC](https://github.com/rust-lang/rfcs/blob/master/README.md process) for new features. This would help provide a clear way for users to propose features, a way for me to warn you in advance when I’m planning something, and a central place to keep track of and discuss such proposals.
It would also be good for the long-term health of the library if there were more than one core maintainer. Hoping hobbyists will fill this role on their own cost is probably not realistic. One way to make it happen would be for one or more companies that are building on ProseMirror to allocate enough time of an employee to become familiar with the system. Another option would be setting up some kind of organization to maintain the library, and channeling money into that.
Then I announced that there exists a working implementation of ‘proper’ table support, with row- and column-spanning supported, and cell selections. This is not currently open, but the company I wrote it for, Atlassian, is not averse to the idea of open-sourcing, so though nothing is being promised, this might become available.
We discussed history tracking and change visualization.
One aspect of that is how you store history. Though the optimal approach depends on your requirements, storing all steps is probably preferably to just having document snapshots. But you’d still want some kind of snapshots so that you don’t have to replay your whole history every time you need a specific version. You can reduce the size of the step history a little by mergin steps, but you’d probably still want to treat this history as something that sits in the database and from which clients can retrieve pieces, rather than something that’s kept in memory as a whole.
Another issue is displaying inserted/deleted content during editing. Some people believed this wasn’t a very good UI pattern in the first place, and showing changes in an un-editable view makes more sense. But if you want to do it, I explained an approach that I’ve been prototyping with the New York Times, where to display changes from a slice of history, you project all insertions to the document at the end of the slice, and style the content they cover as inserted, and project all deletions to the document at the start, and insert widgets showing the content covered as deleted (at the position that you get by projecting the deletion point forward to the end document again).
When documents actually diverge, in the case when you allow users to fork, but also just when someone works offline, you shouldn’t use the same algorithm to merge them that is used for collaborative editing. Rather, some interactive merging approach would be necessary, but no one present knew of existing systems that do this well.
That’s what comes to mind. If you were there and have additional points you feel were interesting, feel fee to add to this thread.
All great points, obviously. I was wondering, is there a way some of us could help you out with the daunting task of documenting? I don’t have the mastery of the API required to help with writing the documentation itself, but perhaps there are tasks one could help you with? Perhaps stuff that takes more time than skill? I’m willing to fork out some of my time to give back to this community.
We discussed this, but since the system is pretty subtle, and the docs have to be very accurate, I think it’s hard to have someone write them who isn’t deeply familiar with the code. One thing that would be very helpful is to open issues for things that you feel require more docs, and to write blog posts and stackoverflow answers and such, so that there’s more resources out there than just the official docs.
Thanks for a great meeting! The better table plugin would be a second good argument for us to upgrade to the current development version, so I really hope this happens.
