Right now, MDN doesn't have full-time staff focused on managing BCD (read more about this on Hacks). As a contractor, this has led to me being a mostly-solo caretaker for BCD, while MDN revises its goals and establishes long-term project plans.
In the interest of transparency and to calibrate expectations, I've decided to lay out my near-term goals for BCD and what I hope that means for the project.
In rough order of priority, this is where my focus is going to be:
I expect other contributors to have their own goals and aspirations鈥攖o scratch their own itch, as it were鈥攁nd I want to support that. In short, I want to help you to help keep the project going.
Points one and two are slightly in tension with each other: sometimes making decisions means breaking with the past. To the extent that I'm able to, I plan to make decisions that permit us to experiment, try things, and change our mind.
The principle that's going to guide me is this: favor decisions that are easy to revert. This may lead to some untidiness in data structure, or writing more verbose notes, or asking contributors for more issues or documentation, but I hope it will ensure that BCD's future can fit into whatever's next for MDN and the needs of BCD鈥檚 other consumers.
That said, I don't expect this exact posture to remain forever, so please expect refinements and changes as we go.
I know several people have stepped up their participation here recently, or continued your ongoing efforts to contribute to BCD. Thank you, thank you, thank you. This is essential to keeping BCD healthy.
CCing @vinyldarkscratch, @jpmedley, @sideshowbarker, @foolip. You're the most active Peers right now, so I wanted to first emphasize my thanks to you. Plus I wanted to make sure you saw what my focus was going to be in the near term. Thank you!
Thank you @ddbeck, it's been a pleasure working in the project so far! The principle of avoiding difficult-to-revert decisions is one that I can easily get behind right now, and is actually one that might help resolve certain long-standing issues, at least tentatively.
For my own involvement in the project, I would say my goals are twofold:
That sounds simple enough when written down, but actually represents a mountain of work. @vinyldarkscratch is doing a lot work here now, and believe we can do it!
For MDN readers and for caniuse.com, the effect I'm hoping for is that the compat tables will never mislead people into avoiding an API which is well supported, or conversely but less common, thinking that an API is widely supported when it is not.
There are also side benefits to high-quality API data that I'm exploring: https://github.com/microsoft/TSJS-lib-generator/issues/918
Most helpful comment
CCing @vinyldarkscratch, @jpmedley, @sideshowbarker, @foolip. You're the most active Peers right now, so I wanted to first emphasize my thanks to you. Plus I wanted to make sure you saw what my focus was going to be in the near term. Thank you!