docs: 2024H1 roadmap and why VoDa supports Ibis #8184
Conversation
|
fixed |
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
docs/posts/roadmap-2024-H1/index.qmd
Outdated
| ### Why does Voltron Data (VoDa) support Ibis? | ||
|
|
||
| Why does Voltron Data employ a Technical Product Manager to work on Ibis | ||
| full-time? Why does Voltron Data employ five software engineers to work on Ibis |
There was a problem hiding this comment.
Do we need the number "five" in here, given that some folks might be joining the team in the future?
There was a problem hiding this comment.
I'll add "currently" or something, but blogs are point in time. I was going to say "(and counting!)" or something but also didn't want to commit to that publicly
docs/posts/roadmap-2024-H1/index.qmd
Outdated
|
|
||
| This writeup of our roadmap is heavily biased toward Q1 of 2024. Looking out, | ||
| our priorities remain much the same. After the big refactor is done, we will | ||
| ensure common DDL support across backends (create table, insert, upsert) for |
There was a problem hiding this comment.
Expand DDL: I'd avoid using an acronym if you are only using it once. It can be confusing for people that are not familiarized with the lingo.
There was a problem hiding this comment.
also, will we ensure common DDL support?
There was a problem hiding this comment.
Let's hold off on publishing statements about broad DDL support. I don't think we've talked about specifics enough to make a decision about user-facing DDL uniformity.
ClickHouse's CREATE TABLE is an example that comes to mind. ClickHouse provides oodles of syntax that will simply never been supported in other backends. There might be a core, but if we go the route of building an API we have to decide to do so collectively and ideally with a plan!
There was a problem hiding this comment.
FWIW I think @lostmygithubaccount is alluding to the ability to insert PyArrow objects, which technically would fall under DML. Maybe it's okay to be specific and say something about insert?
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
lostmygithubaccount
changed the title
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
Co-authored-by: Ian Cook <ianmcook@gmail.com>
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
| geospatial use cases and bridge the gap between geospatial data and other data | ||
| types. | ||
|
|
||
| 5. **Ibis community**: Ibis is an open source project and we want to make it as |
There was a problem hiding this comment.
Should we include a point to differentiate us from other open-core community? We need to build strong trust in the community over time, and it starts with messaging.
There was a problem hiding this comment.
I don't think we need to split hairs on the minutia of open source versus open core versus open standards. Both open core and open standards are open source, but they only make sense in the context of a product and Ibis isn't a product. I think the distinction is useful, but it belongs at the level of a given product not here.
|
|
||
| ### Overall themes | ||
|
|
||
| Our top five themes for 2024 include: |
There was a problem hiding this comment.
Love these themes. We should include a concise sentence to convey the value to the audience for each. For example, why many Ibis backends is important? because user can implement once and execute anywhere
There was a problem hiding this comment.
added sentences...open to more suggestions, I don't love all of them but it's something
|
|
||
| ## Next steps | ||
|
|
||
| It's never been a better time to get involved with Ibis. [Join us on Zulip and |
There was a problem hiding this comment.
Let's spell out what "involved with Ibis" means. It can either be contributing new backends (for xxx value), or integrating Ibis into your own framework (for yyy value), or using ibis as a pandas replacement for (zzz value), etc.
There was a problem hiding this comment.
I don't think this needs additional explication. We have a Contribute tab on the website, which I believe is sufficient for now.
I think a follow up PR that would be useful would be a "How do people use Ibis?" page that spells out the things people do with Ibis that you're asking for:
- Add a backend
- Replace pandas code
- Use ibis as a library
|
|
||
| ## Next steps | ||
|
|
||
| It's never been a better time to get involved with Ibis. [Join us on Zulip and |
There was a problem hiding this comment.
also curious why we decide to use Zulip, somebody asked me today and i didn't know the answer.
There was a problem hiding this comment.
Because a team member expressed a strong preference for it and no one objected.
Having used Zulip for a while now, my personal opinion is that it is a better overall user experience than alternatives like Slack and Discord.
It's less popular for sure, but we chose to prioritize the UX for people who spend the most time on the platform.
There was a problem hiding this comment.
yep we had some internal discussion here -- Discord seemed outright wrong with how it handles threads/code snippets. Slack could have been an option (and we can still consider it), but would probably want a paid version to retain history. Zulip is a free and open source option that fits with Ibis will and has a lot of useful features
| [why Voltron Data supports Ibis](../why-voda-supports-ibis/index.qmd) before the | ||
| roadmap below. | ||
|
|
||
| ## 2024 roadmap |
There was a problem hiding this comment.
Besides the roadmap, do we also have a set of principles for prioritization/design decisions that we should keep in the public? I feel it's important for us to differentiate from an open-core approach to an open-standard approach.
There was a problem hiding this comment.
I don't think we have anything like this, but I'm also not sure we need it at the moment.
I also don't think positioning Ibis using the open core versus open standards terminology is the right approach and adds linguistic overhead and terminology that isn't particularly relevant for many users.
There was a problem hiding this comment.
I do agree this is something we should have (probably a concept article) but don't want to block on the roadmap for it -- it is relatively covered in the "why VoDa supports Ibis blog" that we don't intend to build an open-core SaaS around Ibis or anything
There was a problem hiding this comment.
ok, sg. The reason why I ask is when I spoke to an integrating partner yesterday, I sensed concerns or, at the minimum, a lack of information to understand Ibis' OSS motivation (vs backing company's commercial motivation). I think this blog post will help already; it's just something we'll have to continue to think about and to strenghen trust with the community. Ultimately, what works best is probably just focusing on providing value and exponential growth :)
There was a problem hiding this comment.
+1 on ensuring that we document why Ibis is open source
|
@zhenzhongxu Thanks for the feedback!
I think we've gotten a sufficient number of folks input here: five people other than @lostmygithubaccount have reviewed and/or contributed to the content here. |
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
lostmygithubaccount
added
the
docs-preview
ibis-docs-bot
bot
removed
the
docs-preview
Description of changes
adds a roadmap blog for the Ibis project
Issues closed
closes #7939