All new features are gated behind feature flags that progress from the developing team, to all GitHub employees, then to public over a multi-week span. Larger changes like this one have an internal discussion post shared with the company and a changelog entry once published.
I was responsible for this going out. The goal was to provide a more consistent user experience in that what happens when you click an issue would be the same in more places where we use the issue viewer (sub-issues on an issue, our dedicated issues dashboard (https://github.com/issues), GitHub Projects, and others). Like you mentioned, you also wouldn't lose your place when clicking an issue reference when reading a discussion. There were some performance improvements that came with the change too. It was well intentioned, but we hear you, and thanks for the feedback. We missed the mark on this one and it's been rolled back.
That totally works if it is rare for you! The last 2 months I've had a few things I've added to my personal calendar that synced with work calendar: lunch with a family member, dropping off or picking up car from service, haircuts, contractor stopping by, dentist, vet appointment, etc. It's nice to not worry about it since it marks me as Busy right when I create the event.
Don't Double Book Me isn't some crazy startup idea that needs funding, I am not shooting for the moon with this. Feature development was basically done in a few weekends and I like that it solves a single problem well. There is definitely a market for people who need a tool like this. Look at Reclaim, Calendly, Clockwise, CalendarBridge, OneCal, etc, which have successfully tapped into this market but are focused on selling to teams.
I designed it for individuals balancing personal and professional commitments. I work somewhere with a heavy meeting culture, nothing I can really do about that. I found myself double booked often with personal commitments I had. Consider a scenario where you need to attend your child’s school play, but you forgot to also block off time on your work calendar, now your colleagues think you’re free and invite you to something. You've been double booked.
Events outside your working hours aren’t synced, protecting your personal time and privacy. The default setting is to create events on a destination calendar with the summary explicitly being "Busy" without any other information, but you can change it so it mirrors the event details should you choose.
I’ve been working on Don’t Double Book Me (https://dontdoublebookme.com) the past few weeks out of frustration with keeping my personal and work Google Calendars in sync.
Previously used Reclaim but found $10 a month to keep 2 calendars in sync was excessive and the software was increasingly becoming more team oriented, no longer for individuals. Felt like I was paying for a product and also the product. I just needed to keep 2 calendars in sync, not smart meetings, analytics, integrations, etc. ideally I set it up and forget about it.
I really needed a way to sync my calendars privately, without all the extras. Now that Dropbox has purchased Reclaim, it's even more important I feel like my calendars are not spied on. I knew I could provide a similar service.
Here’s what makes me excited about it as a user:
Affordable: Just $20/year with a 7-day free trial. Cancel at any time for a pro-rated refund.
Privacy First: No need to store events on a servers enabling unlimited calendar syncs.
Working Hours: Adaptive feature that adjusts if an event falls outside your specified working hours.
Round Event Times: Opt to round event start and end times to the nearest 15 or 30 minutes for cleaner scheduling.
Invitations: Block time between calendars when you receive a meeting invitation that you haven't responded to yet. Decline it? The time block on your other calendar is removed.
My plan is to keep it small and focused, while also listening to user feedback for how you'd like to manage your personal and work calendars more efficiently.
A few weeks ago I got the chance to check out the Google Calendar API for the first time and was very impressed how thorough it is.
- Very easy to retrieve incremental changes to events on a calendar
- Webhooks to be notified when calendars are created, updated, or removed
- Webhooks to be notified when events are added, updated, or removed on a calendar
- Bulk requests
- Select only the fields you need from the event
- Querying events in a calendar with custom properties (I use this so I don’t need to store anything on my side)
Funnily enough to build a sync between my personal calendar and work calendar, and for my wife and I to have a combined calendar for our own personal commitments. I also feed in a few calendars I subscribe to for sporting events to our shared calendar. $100 a year was a bit much for a feature that should be in Google Calendar already. I named it Don’t Double Book Me, felt appropriate.
I only started exploring the Google Calendar API recently after realizing that Reclaim’s policy allows Enterprise customers to take over other individual paying accounts associated with the Enterprise, effectively making it not really my Reclaim account anymore. Didn’t help I wasn’t notified of this either.
It's a fair critique! I still keep kicking the can down the road about revisiting the project and modernizing it. The ecosystem has moved along so much since I last revisited it I'll need to take a fresh look at it, accepting the PRs that are currently open is likely out of the question.
> Interest in the ecosystem is shrinking and this is one symptom.
I think the interest in the ecosystem is still very strong, there is just more publicity and marketing around the newest frameworks and capturing peoples attention. Rails is more than ever the best place to go zero to one, and still scaling past 100M at GitHub.
There are so many libraries that are largely feature complete. For example, Devise doesn't need anymore features. There is some traction of going the more lazaronixon/authentication-zero route which is a generator for owning the code rather than having everything live in a gem. This is just one specific example. Rails is moving more and more third party things in house showing it matured in the ecosystem and can move into core Rails.
I find myself reaching to a gem as a last resort if at all possible these days.
Author of peek here. Honestly, I got burnt out. We stopped using this internally at GitHub for our secondary Rails applications which made it difficult to continue working on. Rails was going through its identity crisis with asset pipelines and I didn't feel like trying to support every available option for people like Sprockets, Importmaps, NPM, Bower, etc. It was nice when there was the paved path and users could generally follow the README and be up and running quickly.
C# is used for Actions: https://github.com/actions/runner, and Go is used a lot for internal services. There is no traction rewriting our monolith in C#.
Pacaso allows you to purchase more than 1/8 of a residence, you can purchase as many 1/8 shares as you like. So in theory you could easily purchase 1/4 of a residence.
Pacaso is also purchasing homes that are not yet built, for instance they’ve purchased two homes in North Lake Tahoe that are actively being developed.
I am a 1/8 shareholder of a property in North Lake Tahoe through Pacaso and I love the model. Best of luck to you.
Cased is the developer friendly way to handle production access. We build software to add approval workflows to sensitive operations, record what happened, and link identity providers to command line tools — without frustrating your team.
Our stack currently consists of Ruby on Rails, Go, Postgres, Kafka, and Elasticsearch.
Cased was founded in early 2020 by four former GitHub engineers, product managers, and leaders, with investment from Founders Fund and some of the most experienced angel investors in technology.
Apply on the website if interested or reach out to team [at] cased.com