question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. ItΒ collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

discussion: call for maintainers and future plans

See original GitHub issue

It 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:closed
  • Created 3 years ago
  • Reactions:58
  • Comments:30 (11 by maintainers)

github_iconTop GitHub Comments

9reactions
dan-barrettcommented, Jul 21, 2020

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.

7reactions
BrunnerLiviocommented, Jul 22, 2020

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Maintenance Planning and Scheduling: An Overview
Once the job is completed, they can discuss issues with the planning group to offer helpful information about what went wrong to aid...
Read more >
Communicating with Other Maintainers - The Carpentries
Our monthly Maintainer meetings are an excellent place to connect with the broader Maintainer community, engage in discussions around topics of interest toΒ ......
Read more >
Collaborating with maintainers using discussions - GitHub Docs
You can contribute to the goals, plans, health, and community for a project on GitHub by communicating with the maintainers of the project...
Read more >
Best Practices for Maintainers - Open Source Guides
If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel,...
Read more >
Creating an Effective Maintenance Plan: What should you ...
Exactly what do you need to include to create an effective Maintenance Plan?
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found