discussion: addressing the current state and future plans for the project

[NoNameProvided]

Dear users, maintainers, and everyone!

I am sorry for the long radio silence and inactivity on the Typestack projects. I want to share with you how I am addressing the current situation and the future plans for the project(s).

TL;DR; I have moved to a 4-day workweek that allows me to work a few hours every week on the Typestack projects. I would like to emphasize, that this is not a fixed 8 hours commitment every week, but in general, it should amount to at least 8 hours primarily between Friday and Sunday.

Lessons of the past

This is some personal background story, you can skip this section if you want.

First of all, how did we get here? The past few years were busy for me with work-related (I have co-founded a company) and personal matters. This led to a smaller-scale burn-out along the way that sapped the rest of my energy and motivation for open-source.

There have been a few bursts of motivation here and there when I tried to work on the Typestack projects. Those faded quickly after a few weekends of grinding open issues with no end in sight and seeing the once-a-week opened issues about "is this project dead" and "this project sucks". (I agree, some of the raised concerns are valid, but the kind of delivery matters.)

I also felt immense guilt when I replied to "just some of the issues" as it was unfair that I pick and choose. So I always wanted to "fix the whole" thing in one go. This also leads to me being "afraid" to reply in threads.

Yet, the desire to maintain the projects was not lost along the way so a few months back I requested that I move to a 4-day workweek which was accepted. For a few months, I enjoyed my free time and recharged my batteries. Now I am ready to come back.

To prevent burning out again, I have thought about the root causes. I think the major points were the following:

• low-quality questions (I assume this is due to poor documentation)
• me not closing poor-quality questions but trying to help
• invisible progress for the community - if I answer questions for weeks, everyone else sees that nothing changes in the project
• to some extent ad-hoc feature requests
• to some extent pull requests without a prior discussion about the change

I will explain the proposed solutions for these problems in the next section.

Short-term "management" changes

Focusing on a few projects

While I have big ideas for all the projects in the Typestack organization, as mentioned above fixing everything at once does not work. As a result, I need to choose and pick. I think the biggest win for us is if I focus on class-transformer and class-validator initially.

This means I am entrusting @attilaorosz to maintain the routing-controllers and socket-controllers projects. (I have never been seriously involved with socket-controllers.) He will be the main person responsible for maintaining those projects and for the time being I stay absent from them.

I hope eventually I will be able to contribute to routing-controllers again.

You may ask what about typedi? I think it is in a way better place than the rest of the projects. I am planning on answering questions but no feature is planned at the moment.

Flipping required effort to handle issues from maintainers to the community

I have never closed issues on the spot even if it was low quality, this means an issue that took 2 minutes to write for the author, took me an hour to try to reproduce. This is an unhealthy balance, 8 of such issues will result in me not doing anything else that week. I think this is an often overlooked part but it needs solving.

One may ask why I never closed low-quality questions? Simply I did not want to be an asshole.

To solve this I will enable discussions on all projects but there will be strict standards about opening issues and feature requests. Only the following will be allowed in the issues section:

• bug reports with a minimal reproduction and clear explanation
• well-thought-out feature requests with proposed API and explained rationale with some community consensus
• tracking issues opened by maintainers

The discussion tab will be the place for the community to collaborate and help each other. This means the community as a whole can answer questions, brainstorm ideas, and in general collaborate.

While actionable items will be issues that maintainers (or anyone else) can work on. This will also better reflect the current status of the project because seeing 50 fix issues when evaluating a project may be misleading because, in reality, those are 49 questions and 1 valid issue.

Opened low-quality issues will be closed automatically.

Closing majority of issues

This is a tough one. There are over 500 hundred issues open between class-transformer and class-validator. Even if we make the generous assumption that it takes me 20 minutes to go through a single issue that would mean it takes 7 days (166 hours) just to evaluate them. Calculating with 8 hours a week it means I would do nothing else but read and reply to issues in the next 5 months.

As a result, most likely I will close all issues and non-trivial PR changes with a specific label. Then the community can take up arms if they like and go through the closed issues and organize them, discuss them and open well-detailed bug reports of feature requests.

(I am interested in the opinion of all of you about this change!)

Maintainer changes

There have been multiple maintainers added to the projects over the years but only a few stick. As a result, I will remove most of them except @saulotoledo, @jotamorais, and @attilaorosz.

(If you were a contributor and you think I should not have removed you, please contact me.)

On the other hand, people helping with questions and discussions is always welcome so if anyone wants to help with community management can do so by requesting a Triage role for the repositories from me. (This allows you to assign labels, milestones, open/close issues, and discussions.)

Project goals

I still need to follow up on each project in detail, but generally, the following needs fixed quickly:

• security alerts (we have had issues with them in the past, some were false, but I don't know the current situation)
• reach the 1.0 version with each package (after API stabilization)
• I have acquired the typestack namespace on NPM so from 1.0 packages will be published under it
• package specific changes detailed later

PS: There will be at least 24 hours before I do anything to the projects, to gather some initial feedback about this issue.

Please discuss: share your opinion, and raise your concerns. I am here listening.

[NoNameProvided]

If I would have written down all the current problems and ideas to solve them, I would have written that message all day long. (Example: discussions and triage role solves the problem of users not closing their own questions.)

So if anyone has some ideas that please share and discuss them!

[attilaorosz]

have acquired the typesctack namespace on NPM so from 1.0 packages will be published under it

I hope "typesctack" is a typo :)

[NoNameProvided]

I hope "typesctack" is a typo :)

Good catch, updated it!

[braaar]

Happy to see you're back!

Very good observations and ideas for improving things. Well said about time consumption and issues. We cannot let the project be hamstrung by low quality issues and questions.

I am eager to help out in dealing with the backlog of issues. How does one contact you to request a triage role?

A gentler way to close issues without commenting
I have an idea for how we can improve the speed and ease with which we can close issues, without feeling guilty about not leaving any helpful comments.

I have posted this idea in the discussion tab.

[ytetsuro]

Closing majority of issues

API to all issues, "Are you still in trouble?" and comment.
If there is no reply to that comment for 5 days, how about unconditionally close?
Sounds like a somewhat violent method, but I thought it would be a good way for you to spend less time reading issues.

[NoNameProvided]

How does one contact you to request a triage role?

Just like this. I have invited you with the triage role.

API to all issues, "Are you still in trouble?" and comment.

Yes, if I am closing automatically, then I will post a comment linking here for reasoning and letting them know if their issue still persists, they can open a discussion about it.

Yesterday I answered and closed around 70 questions in roughly 6-7 hours. That is pretty good progress, so I may try to close issues one by one instead of mass closing. We will see.

If there is no reply to that comment for 5 days, how about unconditionally close?

I am very much against closing issues due to inactivity. I find it kinda shitty, having no activity doesn't mean the problem is solved. What we do is we lock closed issues after 30 days, so no one can revive years-old issues.

What we need to do is educate the community that if you have a question or just an idea then you need to open a discussion. I will add this via a Github template probably.

My end goal as I mentioned in the original post is to have only actionable items (confirmed bugs and fully detailed feature requests) as issues. That will be a much lower number than the current open issue count.

For the discussions, I will make it clear it's managed by the community and there is no obligation from my side to provide support for general development-related questions.

[braaar]

Thanks for the invite! I'm happy to be on board the triage team. I have set a goal to close at least 3 issues in class-validator every day. I'll try to also be vigilant and direct incoming questions to the discussions tab.

[gterras]

Thanks for posting this very relatable. Class-tranformer and class-validator are wonderful projects that the JS ecosystem definitely needs.

A few random thoughts:

One may ask why I never closed low-quality questions? Simply I did not want to be an asshole.

I'm pretty sure you don't come off as an asshole if the rules are stated and clear, you just come off as a serious maintainer. A mandatory repro link field is a great idea, you can add some additional info to it:

As a result, most likely I will close all issues and non-trivial PR changes with a specific label.

That seems like a reasonable solution considering the situation. If I may add please consider NOT adding the no-activity auto-close bot which is by nature awful and useless on a well maintained issue tracker, and actually gives a "maintainer does not care" vibe.

To solve this I will enable discussions on all project

No doubt Github Discussions are a great way to keep a clean issue tracker. You can also turn issues into discussions.

Thanks for you hard work and long life to typestack <3