Setting up a maintainence team?

So, off the back of this bit of conversation: https://github.com/encode/orm#issuecomment-511196050

I’m wondering if now would be a good time to create an encode maintenence team covering the async web stuff.

  • uvicorn
  • starlette
  • databases
  • orm
  • typesystem

I think we’d probably try to start out with a fairly tightly defined set of responsibilities (be able to roll new releases, no API changes without approval, no structure/project managment style changes without approval), but it’d be great to have a handful of folks with appropriate permissions to deal with bug fixes without everything having to come through me.

Any thoughts?

1 Like

Your link seems to be broken, here’s working one:

https://github.com/encode/orm/pull/38#issuecomment-511196050

1 Like

Very good idea! I’m all in on this and I’d love to see this happen.

I maintain several projects myself though, so I’d need to evaluate how much I’d be able to dedicate to one of these projects and my current opinion is that my plate may be a bit full.

Idea is good, starting out safe - with limited responsibilities - should also work. Ultimately the goal here is to create an async toolkit for web apps and services. This is a hefty task for single person, even with hop-in assistance from volunteers and full-time commitment there’s a lot of things that require attention.

I think the best material for potential encoders would be people with some sort of stake in projects involved, basically people are already using those in their project.

Initiatives like Palettes and JazzBand also come to mind - I think in longer run Encode would benefit from turning into umbrella org for ecosystem of libraries solving different problems (databases, orm, http, validation, caching, passwords, etc. ect.) with people cooperating on those. But I can understand if this will be complex issue for @tom - Encode is a brand and legal entity with sponsors and money involved, and creation of new label would confuse people and require new promotional work.

Agreed. In any case, always best to have as maintainers people who actually use / rely upon the software being considered.

Starlette and uvicorn are probably the two most mature / relied upon projects here.

OTOH, it seems the typesystem/databases/orm trio is in a good MVP stage, but still WIP, so I’m not sure the user base is as dependant yet. The amount of pending issues/PRs over there is a very good indicator that these solve real problems in the async space, though. So it should still be possible to find people interested (as in having interest) in seeing them develop and willing to take some responsibility in their maintenance as a result.

On this note, the idea for starting small and progressively adding upon existing responsibilities sounds very sensible.

That’s definitely a good idea and something that feels required indeed.
Strict responsibilities and permissions for start are also nice as it brings clarity and also helps to establish understanding and teaming in general, so guidance might be adjusted as it goes.

I’d love to join/help with it and I’m generally excited with all projects from the async pool, I’m probably less familiar with typesystem.

I’d also like to help to speed up the orm project. And the async orm still feels like something not properly filled in general.

I have a full-time employment, so it might bring some constraints with time, but I think I still have some capacity.
And I have one project running on uvicorn + starlette + databases.

At Mirumee we hope to use more and more of the encode stack (I’m looking at you, orm) so it could be possible for me and @rafalp to handle bug fixes related to the stack as part of our jobs. We would definitely love to talk about where the APIs are headed, with @tom having the final say of course.

2 Likes

That’d be pretty ace. Thanks @patrys.

So I think the split for teams would probably be something like:

  • HTTPX Maintainers (httpx) @florimondmanca, @sethmlarson, @yeraydiazdiaz
  • Web Stack Maintainers (uvicorn, starlette) Who’s keen here. I’m thinking about getting in touch with @tiangolo (Sebastián Ramírez, FastAPI) @gvbgduh maybe?
  • Database Maintainers (databases, orm) Darrel O’Pry has expressed interest. @patrys If the Mirumee team are keen too then I think we could get on a good role there?

I’ve not thought about where typesystem would fit in there?

2 Likes

I would be honored! :grin: :rocket:

@tom I’ve asked about this internally and I’m not allowed to make any promises here. I’m definitely interested in helping databases and orm grow but at this moment as a company we can’t commit to regular maintenance work.

Hi @tom,

I’m happy to assist @tiangolo with uvicorn and starlette and I’d like to take care of databases and help with orm in coordination with @patrys as it happened that I’m keeping some amount of context of databases.

@gvbgduh, @tiangolo - I dropped the ball here for a bit due to personal circumstances, but I’m focusing on this again. I’ve set up a “Web Framework” team and invited you both.

Key points:

  • I’m still trying to get to grips with supporting Encode as it grows, so if there are any big decisions that need my attention, please email me directly.
  • API changes should probably be run by me first, at least for now.
  • Let me know when you need to cut a PyPI release, and I will deal with sorting appropriate permissions there.
1 Like

Thank you @tom, it’s the pleasure.

1 Like

The same here! Thanks @tom, it’s an honor! And hello @gvbgduh :wave:

I have a bit of backlog with some personal/legal stuff, so I’ll probably be a bit quiet for a bit. But I’ll be back on schedule in the next weeks. :smile:

1 Like