New Ideas and discussions

[Muawiya-contact]

@masukai, we can discuss here about something important about the Drt-hub

[masukai]

Thanks for opening this @Muawiya-contact! 🙌

What's the topic you'd like to discuss? Feel free to share specifics — bug ideas, feature proposals, architectural questions, or community/growth ideas are all welcome.

For focused conversations, the convention here is one Discussion per topic (so it's easy to find later). If you have multiple ideas, splitting them into separate Discussions in the right category (Ideas / Q&A / Show and tell) works best 👍

Looking forward to hearing what you have in mind!

[Muawiya-contact]

GSoC Opportunity for drt-hub

Hi @masukai,

I'd like to suggest Google Summer of Code (GSoC) for drt-hub. The project is well-positioned for it:

Why drt qualifies:

• 21 destinations + 10+ sources with clear patterns
• Active development with thoughtful architecture (feat: add response pagination support to REST API destination #260, Implement Dynamic Connector Registry System #381)
• Real-world impact as a production reverse ETL tool

Potential GSoC Projects:

1. Pagination Feature (feat: add response pagination support to REST API destination #260) — Standardize across REST API destinations
2. Source Connectors — Add Salesforce, Zendesk, etc.
3. CLI Enhancements — Validation, debugging, dry-run improvements
4. Observability — Metrics, benchmarking, monitoring tooling

How I can help:

• Draft GSoC application & project descriptions
• Mentor contributors on the architecture
• Document connector patterns for onboarding

Let me know if this interests you!

[masukai]

Thanks for this suggestion @Muawiya-contact! I'm very interested in GSoC for drt-hub.

Looking at the timeline — GSoC 2026 organization applications closed in February, so we can't join this year's round. But I'd love to target GSoC 2027 (org applications typically open January).

Here's what I'm thinking for preparation:

1. Build the project ideas list — we already have plenty of well-scoped issues. We need at least 4 solid ideas with clear mentoring plans.
2. Grow the contributor base — GSoC orgs with an active community have better chances of acceptance. We're on a great trajectory with 10+ contributors already.
3. Document mentoring patterns — our PR review process is already close to what GSoC mentoring looks like.

Your offer to help draft the application and mentor is much appreciated. Let's open a dedicated Discussion for GSoC 2027 planning closer to the end of the year.

In the meantime — have you looked into Outreachy? They run twice a year and may have an upcoming round we could explore sooner.

[Muawiya-contact]

Nice approach @masukai. We will stand up the drt-hub in GSoC 2027.
About Outreachy, I will take a look at that.

[Muawiya-contact]

@masukai, have you ever thought about building and hosting the official Drt website? SO, it will download from the official website as well and increase the number of users. Also, we should publish the official Py library of the drt tool in the Python Official package(PSF).
What's your opinion?

[masukai]

Great ideas @Muawiya-contact — thanks for keeping this thread alive! 🙌

On publishing to PyPI: good news — that one's already done! drt has been on PyPI for a while and you can install it with:

​bash pip install drt ​

(latest is v0.7.9 → https://pypi.org/project/drt/). So that box is already ticked ✅ — but it's a great reminder that we should make this more discoverable, which ties directly into your next point.

On an official website: strong yes from me. 👍 This has been on my to-do list for a while and I just hadn't prioritized it. I'm imagining something like a landing page (LP) — clear value prop, "why reverse ETL with drt", the connector matrix (21 destinations + 10+ sources), a quickstart, and links into the docs — plus install/getting-started flows that funnel new users to pip install drt.

The one thing I care a lot about: the GitHub repo must stay the single source of truth (SSoT). I don't want a website that drifts out of sync with the README/docs/connector list. A few ideas to enforce that:

1. Generate, don't duplicate — build the site from the repo's existing docs/ and README using a static site generator (MkDocs Material, Docusaurus, or Astro Starlight are all good candidates). The repo content stays canonical; the site is just a view of it.
2. Auto-sync via CI — a workflow that rebuilds & redeploys the site on every release / docs merge, so the site can never fall behind a release.
3. Connector list from manifests — generate the destination/source matrix from the plugin manifests rather than hand-maintaining a list (so new connectors show up automatically).
4. Live version/badges — pull the current version straight from PyPI so it's always accurate.

For hosting, GitHub Pages / Cloudflare Pages / Vercel would all work and are free for OSS.

Logistics & how we'd split it:

• I can set up the infrastructure side — a dedicated repo (e.g. drt-hub/website or drt-hub.github.io), hosting, domain/DNS, and the CI sync workflow.
• If you'd like to take the LP design & build (layout, copy, the marketing-facing page), that would be a fantastic contribution — and I'll provide the SSoT/sync guardrails so it stays maintainable.

To keep things organized (and per the one-topic-per-Discussion convention 😄), want to open a dedicated Discussion in Ideas for "Official website / landing page"? We can scope it there — pick a stack, sketch the page sections, and define who does what.

What stack are you most comfortable with? That'll help us pick the path of least friction.

[Muawiya-contact]

Exactly, @masukai. First of all, this discussion is just for new ideas; then there will be a dedicated discussion on each topic.