More maintainers required?

[curran]

Having submitted several pull requests that improve documentation, none have received any attention from maintainers for over 2 weeks.

I understand that life is busy, and working on ShareDB may be a low priority, but I feel the project could be made better if PRs were acknowledged in a more timely manner.

For example, there were two questions asked by @nickasd in various issue threads that could have been avoided if the documentation PRs were merged in a timely manner:

• Question on how to use "undocumented" projection feature
• Question on using document.removeListener()

It appears that currently only @rkstedman and @nateps (and maybe @avital) are able to merge pull requests. One solution to this issue of timely collaboration would be to add more maintainers to the project, with permissions to review and merge pull requests. Is this a possibility?

[nickasd]

This is such a handy library which could be the base for a lot of web applications. It would really be a pity if it wasn't maintained anymore.

[nateps]

Hey all! We're definitely planning on continuing to maintain. I've taken on additional responsibilities at Lever in the past 6 months that mean I've had to step away from day-to-day coding for the time being. We're growing the team substantially in the next 12 months, and it is explicitly on my objectives for the second half of this year to train engineers to take over the ares in which I have been the owner. Thanks so much for your interest and support for this project! It is a great signal of the value of the project to see your asks for continued development. I am excited to get to a world where we can have community maintainers help us to scale. In order to achieve that, we do need people that have enough historical context and expertise with the project over a long time involved in planning and leadership. There is a lot of knowledge that I was able to get from working closely with Joseph, the original author of ShareJS for a year and a half, and that has helped us to keep the project moving along and improving. I plan to do something similar in working closely with additional engineers and we are hiring full time engineers to work at Lever to work on the project. I hope to have good news to announce in short order along this front!

…

On Tue, Jul 4, 2017 at 2:28 AM, Nicolas Kick ***@***.***> wrote: This is such a handy library which could be the base for a lot of web applications. It would really be a pity if it wasn't maintained anymore. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOLNMkJB3NLkbbynJqGIhkQGUrHkSs1ks5sKgXBgaJpZM4OM7DR> .

-- <l-signature name="Nate Smith" title="Founder and CTO" href="https://lever.co/" on-receive="reply()"> </l-signature>

[curran]

@nateps It's great to hear this! Thanks for your response here. Looking forward to see this project thrive.

[curran]

Would anyone be able to please review/merge this documentation PR on sharedb-redis-pubsub?

share/sharedb-redis-pubsub#7

It's been pending since June. Thank you.

[curran]

I've made some notes on issues that can be closed, and PRs that can be safely merged as-is:

Closeable Issues

• Couch DB support Couch DB support #131
• Renaming documents Renaming documents #143 (closed 👍 )
• Native iOS/Android version of Derby/sharedb Native iOS/Android version of Derby/sharedb #181
• add custom actions add custom actions #177 (closed 👍 )
• Servers as peers to each other? Servers as peers to each other? #158

Mergeable Pull Requests

• typo on log message "Ignorning" typo on log message "Ignorning" #176 (closed 👍 )
• Reconnecting Websocket Example and Updated Readme Reconnecting Websocket Example and Updated Readme #138
• Remove unused Duplex variable in example Remove unused Duplex variable in example #157 (closed 👍 )
• Link to sharedb-wsbus-pubsub Link to sharedb-wsbus-pubsub #184 (closed 👍 )

@nateps @rkstedman @josephg @avital I think there is a perception ShareDB is dead. Closing these issues and merging these PRs as-is would benefit the project by showing "signs of life". I don't believe they need thorough review, if it's a case of "no time for the project".

Anyone else listening in here wanting to contribute - please comment on the issues and PRs noting whether you agree that they can be safely closed/merged. Thanks!

[dcharbonnier]

@nateps the core of the problem is this "historical" background required, with good contracts between the different elements, unit tests and a bit of documentation it should not be too complicated for a project of this size. If not, maybe focusing on providing the required information should be the first goal. I can help on that.

[ile]

@nateps, what do you think of the native iOS/Android version of ShareDB/Derby? Would be useful, IMO.

I left a bunch of GitHub issues around asking for opinions on creating that, fox example derbyjs/racer#254.

[curran]

Closing as I've seen a slow churn of activity since opening this, and recent activity by @nateps woohoo!

[nateps]

:-) We're getting there!

[curran]

This PR looks mergeable to me, and IMO would be a nice "sign of life" to have reviewed and merged :)

• Fix server crashing on failed publish Fix server crashing on failed publish #201

[curran]

Reopening as PRs are going stale and being merged in active forks.

This fork looks to be the most active: https://github.com/Teamwork/sharedb/network

Maybe consider giving someone the ability to merge PRs in this repo?

[curran]

I'm switching dependencies over to @teamwork/sharedb and other ShareDB-related packages under https://github.com/Teamwork, as @gkubisa et. al. are doing a fantastic job of maintaining them.

I hope a vibrant ShareDB community can grow in @teamwork/*.

Related discussion in #207.

[gkubisa]

First of all, I maintain the forks at @teamwork/* out of necessity because my company depends on the bug fixes and features missing from the main repo. It's not my goal to build a community around my forks because I think it would just lead to fragmentation and confusion. I'd rather see PRs getting merged into the main repo, so that we could build one vibrant ShareDB community. I realise that it takes effort and so I'm willing to help.

@nateps, would you consider granting push access to the "share" organization to more people, so that PRs would be processed in a more timely fashion? I'd be more than happy to help with that.

[ericyhwang]

Good news! (I'm posting this for @nateps since he had to head home.)

Nate's committed to holding weekly PR review meetings starting next week, and he'd like to have it a time where at least @curran and @gkubisa can join virtually.

Scheduling-wise:

For next week, he's penciled in Wednesday, June 27 from 10-11 AM PDT (5-6 PM GMT, 6-7 PM BST). His schedule is pretty packed on other days, but the specific time on Wednesday is flexible. @curran, what time zone are you normally in?

I just realized that the UK does Daylight Savings, though, so 9-10 AM US Pacific / 5-6 PM BST would work for us too. (To be exact, 16:00 UTC while the US is on Daylight Time, 17:00 UTC once the US is back to Standard Time.)

[gkubisa]

That's great news Eric! I'm usually available on Wednesdays at 16:00 UTC, except for the next 2 weeks - busy time at work and then holidays. I'll be back on 9 July.

[curran]

I'm in India time, so AM PST works for me (the earlier the better, not later than 10:30) . I have a weekly call from 9:30-10 PST Wednesdays, so could join a call before or after that slot. I'm not sure I can join on an ongoing basis but I'd be happy to join for at least the first few meetings. Thanks @ericyhwang and @nateps !

[gkubisa]

Hi @ericyhwang, @curran, are we going have the review meeting tomorrow at 16.00 UTC?

[curran]

I'd love to participate in meetings.
I didn't hear back from @ericyhwang or anyone else, so I think no one planned it.

[ericyhwang]

@gkubisa @curran - We are on for Wednesday July 11 at 16:00 UTC!

Nate and I did get something scheduled, but we were trying to figure out a good way of inviting you two without needing you to post your emails publicly.

For now... I'll post a temporary Zoom web-meeting link here about 5 minutes before 16:00 UTC. It'll require you to download a client app. If you want to download it beforehand, you can do so here: https://zoom.us/download#client_4meeting

During tomorrow's meeting, we can take some time to discuss how to get future meetings set up, publish meeting notes, etc.

[ericyhwang]

(This had the temporary web meeting link for July 11, I've now removed it as the meeting is over.)

[curran]

Thanks everyone for pulling the meeting together! Really great.

@ericyhwang I'm dropping my partial notes here. Feel free to integrate these into yours if you post a digest to the mailing list.

Where to post notes? ShareDB mailing list.

Nate: Thoughts on moving forward:

Thought behind Eric working on this - he's quite experienced. Different ways to prioritize - should we maintain Derby? Yes, as Lever has a large codebase that depends on it. It was built before react. Derby will take some time/prioritization.

More people outside Lever have chosen to use ShareDB, compared to Derby, so it makes sense to support it as well. Would like to merge efforts a bit.

In terms of bringing on additional maintainers, at what point would you (Nate) feel comfortable doing that? It would be nice to have more people as maintainers. A precursor to doing that is getting into alignment on a direction. We need to have a baseline on what types of capabilities the platform should have. We also need to establish a code review process, with an understood level of quality. For example testing should be required.

[ericyhwang]

Thanks for leaving your notes!

Couple more things Nate mentioned about additional maintainers:

• Maybe start with two-eyes-on-a-change for a while, before moving to people merging things in solo
• We may end up having certain maintainers more specialized in some areas that they're comfortable accepting changes, and for other changes they consult other maintainers

As a personal note, I'd love for Greg/Curran to onboard as official maintainers for Share, as they have more experience in the Share codebase than I do. That'd also mean I could put more of my split time into DerbyJS, which has fewer contributors outside of Lever.

For now, we'll continue holding these PR review meetings with at least Nate/Greg/me (and Curran when he can make it), as it's a good way to learn from Nate's thoughts on the PRs.

PRs reviewed during meeting

We went through @gkubisa's open PRs, as he was there to talk about them.

• Ready to merge - @nateps will take care of merging and publishing in the next day or two:
  • Do not compose create with op #213
  • Allow op to be a non-object #217
• Should be good to go, but before merging, @nateps is going to read through Share code related to the PRs as a sanity check:
  • Emit error on failed resubscribe #174
  • Fix hasWritePending in op's callback #205
• @gkubisa to do some more updates on these, based on discussions:
  • Fix Doc.prototype.destroy #204 - Small tweak, doable quickly
  • Implement undo/redo #216 - Will need some more experimenting with doing undo/redo stack across multiple docs
• Deferring until next week's meeting:
  • Sync ephemeral presence data #207 - We felt Presence would probably take more time to discuss, so we prioritized the other PRs this week.

Next week

Review Presence and the other PRs we didn't get to this week. If we have time, we'll look at PRs in the other repos like sharedb-mongo.

[gkubisa]

Thanks for the meeting guys. I'm glad to see the project moving forward. 👍

Re the next review meeting, it would be great to also have a look at #220, which I think is already in a pretty good shape.

[dcharbonnier]

We are few active on this project but some discussions take place on github and could be more efficient and less noisy on irc or slack or something else. Can we open a slack for that ?
Exemple #223 #220

[alecgibson]

I'd be very keen for Slack.

[dcharbonnier]

for now I created https://gitter.im/sharedb/Lobby# but if @nateps want to create a slack community I would be happy

[gkubisa]

Here are the PRs from outside ShareDB I'd like to merge soon:

• Fix tests sharedb-mingo-memory#5
• Improve performance of getLinkedOps sharedb-mongo#58
• Features/upgrade packages sharedb-mongo#59 -> it requires some updates because it depends on Fix tests sharedb-mingo-memory#5. I'll make it ready to merge as soon as Fix tests sharedb-mingo-memory#5 is merged.

[curran]

FWIW, there's already a Gitter channel for the project https://gitter.im/share/ShareJS
We could leverage the existing members there by just starting to use it, instead of creating a new channel.
Or, maybe a new channel is fine. Let's see how it plays out.
I do love Slack as well.

[dcharbonnier]

I didn't know there was already one, that's why I created it, you're all admin of this new one.

[alecgibson]

Is there a PR meeting happening tomorrow? If so, I've got a bunch of PRs open against various parts of the Share stack, which I'd love to have looked at please 🙏

• Add support for fetching a particular version of a snapshot #220
• Store custom client ID on Agent/Connection ID #224
• Improve performance of getLinkedOps sharedb-mongo#58
• Throw when array and object deletion values do not match current version ottypes/json0#23

[ericyhwang]

Yes, we're still on tomorrow.

I've been out sick, so I haven't had a chance to do much this past week besides sleep a lot. I should be recovered enough by tomorrow to dial in.

I'll post the meeting link a few minutes before 16:00 UTC, same as last week.

[ericyhwang]

2018-07-18 meeting notes

(I'll also start posting these to the maiilng list.)

In the past week, Nate has been mostly focused on finishing out pending work in Derby, which will be done this week. He did merge in the WebSocket reconnection PR (which one?), and he switched the examples over to the Teamwork version of websocket server.

PRs we looked at:

• Add support for fetching a particular version of a snapshot #220 (getSnapshotAtVersion - Alec)
  • If you’re going to get an older version of a snapshot, you’re going to either rewind ops from the current snapshot with inverse, or start with the original create and replay the snapshots on top.
  • How do we handle revert to a previous version cleanly? You could do a diff-match-patch with the target version like Git does, or you could invert the ops from between the target version or now.
  • We don’t want to back ourselves into a corner API design wise, by returning just the snapshot data and just letting the user use it as they want.
  • submitSnapshot from the undo/redo PR uses diff/diffX on the OT type to submit the snapshot
  • Action items:
    • Add a base Snapshot class, have MemorySnapshot and eventually MongoSnapshot inhert from it
    • Return an actual snapshot object, i.e. change version to v
• Store custom client ID on Agent/Connection ID #224 (customizing clientId - Alec)
  • Goal is to attribute ops to specific users
  • Customizing is a good idea
  • If we allow customizing, we should allow customizing the clientId entirely
  • Putting custom clientId as a prefix means it can be queried efficiently with Mongo
  • Eric: We use server-side ShareDB middleware to store attribution info for an op on the op meta. Downside is that you don’t get that info in the client, which in our case is intentional.
  • Nate: We can certainly add an option to return parts of the op meta to the client, with a customizable projection.
  • Alec has decided to close his PR and put the info on the op meta.
• Improve performance of getLinkedOps sharedb-mongo#58 (improve perf of getLinkedOps - Alec)
  • Hooray performance improvement! Looks good to merge.
  • We’ll want to fix up the tests first, though. Greg has two PRs against sharedb-mingo-memory and sharedb-mongo to fix them. Eric will take care of handling the merge and publish of them.
• Implement undo/redo #216 (undo/redo - Greg)
  • Making good progress
  • Brief discussion around naming of undoComposeTimeout, which controls how close a new op is to previous ones for the undo manager to compose them. Decided to rename to undoComposeInterval.

PRs we didn’t get to:

• Sync ephemeral presence data #207 - Presence

Action items:

• Eric: Merge and publish Fix tests sharedb-mingo-memory#5 (done, published as [email protected])
• Greg: Update Features/upgrade packages sharedb-mongo#59 to use the published sharedb-mingo-memory version, assign PR to Eric for merging and publishing
• Nate: Merge and publish a couple sharedb PRs from last week, or grant publishing permissions to Eric and delegate to him:
  • Do not compose create with op #213
  • Allow op to be a non-object #217
• Nate: Take a last look at these PRs, then merge+publish them:
  • Emit error on failed resubscribe #174
  • Fix hasWritePending in op's callback #205
  • Fix Doc.prototype.destroy #204
• Eric to investigate putting multiple NPM repos into one GitHub repo, to see if it’s feasible to combine sharedb-mingo-memory into sharedb-mongo.
• Greg and Alec to continue work on their PRs
• Eric to add Greg, Curran, and Alec to the recurring calendar invite. We will probably still post the meeting link publicly, in case others want to join.

[ericyhwang]

Hm, there are over 300 members of the sharejs Google Group, so I'm not sure about posting full meeting notes to the group.

Perhaps I can create a separate group for the full meeting notes, and just post a condensed summary and a link to the sharejs group?

Alternatively to creating a new group, I could make a Google doc for the meeting notes, and link to them from the summary in the main group.

[curran]

@ericyhwang I'm curious, what is the concern with having all 300 people know about what went on in the meeting?

Perhaps we could use the Wiki feature of GitHub for the full meeting notes, and link to those instead of a Google Doc. That way it will be more tied to the project, rather than someone's Google account.

IMO it would be great to be transparent. The list is pretty dead anyway and this would liven things up for sure. If the concern is that it's too noisy, I think folks can leave the mailing list if they are not interested.

[ericyhwang]

@curran Just concern about noise was all! I can certainly start by posting the full notes and ask if people would like just a summary instead with a link to full notes.

Good idea about putting the notes in the GitHub wiki! I should have time tomorrow to get that up.

[ericyhwang]

Notes from the first two meetings up on the wiki:
https://github.com/share/sharedb/wiki/ShareDB-PR-Review-Meeting-Notes---2018#2018-07-18

It's currently set so that any signed-in user can edit. If I can't make a meeting, someone else can take notes and put them there.

Tomorrow, I'll write up a blurb to send to the sharejs mailing list about the resurrection of the meetings, a summary of work in progress, link to the notes, and how to join the meetings. Anything else?

[curran]

Awesome! Thanks @ericyhwang