discussion: call for maintainers and future plans
See original GitHub issueIt is clear that we need help maintaining this project.
TypeStack projects/repositories are used in a lot of production environments today and the size of the code base as well as the issues, backlog and future project direction that we have to review - it all deserve more attention then itβs currently getting from me.
Iβd like to suggest a couple of things:
Maintainers:
We can leverage Githubβs Teams and perhaps create different teams and associate them with the different TypeStack projects/repositories and grant proper permission to individuals on those teams and to the repositories those teams would be associated with. Example:
TypeStack
βββ Core
βββ class-sanitizer
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ class-transformer
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ class-validator
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ microframework
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ model-controllers
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ one
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ routing-controllers
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ socket-controllers
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ typedi
β βββ maintainer-team
β βββ reviewer-team
β βββ triage-team
βββ typestack
βββ maintainer-team
βββ reviewer-team
βββ triage-team
We could then assign individuals to those teams (preferably individuals that are already top-contributors of those respective projects/repositories) and grant the appropriate permission (we could check each project for the active contributors - members that havenβt been active on TypeStack for the last year, wouldnβt be considered).
If you are still interested, let us know your thoughts. If not, no hard feelings and thank you for your critical contributions.
Note that I will not be withdrawing from the project at all. TypeStack projects are very dear to me, but I need help.
Project Management
I think we have to define clear standard project management practices such as:
- Clear release cycle and respective plan and roadmap
- Project board for each project
- Issue template (with checklist or steps on how to reproduce the issue, actual result, expected results, etc)
- PR Template (with checklist for test coverage, documentation, samples, etc)
- Increase continuos Integration
- Adoption of Continuous Deployment to NPM, based on release/tag creation
Future state & roadmap
We should also reconvene and analyze the projects goals and make sure we have more adoption (from usage and development contribution perspectives). There are a number of things that we can do on this front:
- Reevaluate the roadmap and also existing features and check what can be deprecated, removed and what should be implemented or changed
- Static documentation generator or wiki, for live documentation (we could use things like docsify or Slate, for example
- A TypeStack website, with references to features, documentation and samples
If you have any comments or alternative solutions, let me know.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:58
- Comments:30 (11 by maintainers)
Thanks for your input @RyanCavanaugh . I think my ask is a little different than that specific FOSS fund. In fact itβs more broad than TypeStack and this thread; Iβm just taking advantage of a relevant thread to surface something many of us have considered for a while. I think my ask is aligned with Microsoftβs business strategy, your personal interest in seeing Typescript flourish for the long haul, and our interests as a community in building stable full-stack applications in what has become my favorite language. My ask is only that you bubble up what follows to the powers that be inside the Microsoft organization.
For obvious reasons, Typescriptβs first home was the front end. And given the nature of the playing field there, a handful of large web companies lead the way in library development. This yielded fantastic stable frameworks and libraries for the front end. But as Typescript has matured, weβre seeing a push for the full-stack use case. I work for a company that is an early adopter of full stack Typescript. And for a company like mine to commit to using Typescript up and down the stack, we need build tools, a server framework, an ORM, and all the little libraries in between that glue everything together. Thereβs an incredible organic community that has supported this movement; indeed they are the prerequisite for what weβre even trying to accomplish.
None of these libraries have the same adoption rate as Angular or React or any of the front-end use cases- yet. But already the npm pull-frequency of many of these libraries is only one or two orders of magnitude away. Full stack Typescript is coming and weβre excited for it. That said, many of these libraries (though not all) are plagued with the kinds of problems youβd expect in young open-source software packages: poor or outdated documentation, slow issue resolution, and sometimes disappearing maintainers. This isnβt a knock on the people who wrote and maintain the libraries, the authors are often doing it entirely on their own time and at their own expense. But as Typescript matures as a full-stack language, so must the libraries that enable its full-stack use.
Strategically, the FOSS fund linked above has different goals than those I envision: Iβm asking for an initiative centered around full-stack Typescript specifically. I donβt know what exactly that looks like. It may not involve you personally or even the core Typescript team, but Microsoft as a company has the credibility and experience to lead the way here. It may be that Microsoft assumes ownership of development and maintenance for certain high-use libraries. Or it could be a little more detached: some Microsoft-backed FOSS organization specifically for the full-stack Typescript ecosystem. Maybe itβs as simple as leading by example and forming a pool of companies who use full-stack Typescript to contribute to the costs of development and maintenance.
Whatever it is, I think we can make the case that it benefits Microsoft as much as it does the rest of us. If Microsoft has any stake in people using Typescript, surely the company carries stake in stable, well-documented, well-maintained libraries that enable its use. And more than that, it benefits Typescript as a language: we love Typescript and we want to use it across the stack!
And again, to reiterate @RyanCavanaugh, weβre not asking you or the rest of the core TS team to do double duty in your free time or even bake this into your day jobs. Instead, Iβm asking that you bubble these ideas up to the powers that be inside the Microsoft organization. We think if they are listening and they act on it, everyone wins.
Iβve promoted this issue in the NestJS Discord Server (8.2k members) in the hopes of enthusiastic Nest community members to pick this up and contribute. Most of the NestJS team members, including myself are unfortunately quite occupied with our day-to-day jobs on top of maintaining the framework. At least from my part, I wonβt be able to commit to a role, unfortunately.
I think it would be a great to bring a closer community together. NestJS has switched from Gitter to Discord as well and it helped us a lot to boost our community and leverage intrinsically motivated people. Iβd be happy to promote whatever chat you want to use as well in our Discord. We have a
#partners
channel where we try to promote other communities related to Nest.