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

[Walnussbaer]

@NoNameProvided I just stumpled upon your projects. Our team is just starting to use your class-transformer in our project and we already gathered some experience using it. It's really awesome! I really appreciate your honesty and wish you all the best! I definetly agree with all the ideas you posted in your initial post and I'm looking forward for future updates on the class-transformer project!

[bdarcus]

You have discussions turned on in this repo. Perhaps you could turn it on for the class-transformer one also, and push all questions there?

For it to be useful, it would likely require community members to answer questions.

[julianpoemp]

It's really unfortunate that class-transformer and class-validator didn't receive updates for the last two years and won't receive any updates in the future (as it seems). This package is an important part e.g. of NestJS development and recommended from NestJS docs even if it's deprecated.

[braaar]

@julianpoemp if you want to help out I'm sure you can get a triage role so the incoming issues can be handled better.

[TechQuery]

ECMAScript Decorator proposal stage-3 support is in my wishlist: #1929 (comment)

I use Class Validator to check Uploading Data in Front-end: https://github.com/idea2app/MobX-RESTful/blob/f9615f4d378fa7ca018add9e16d6bae6d82014c1/test/example/UserStore.ts#L13-L16

[emir-gradient]

Hello.

I would like to contribute to this project by answering questions, resolving bug-fixes or incorporating new features when there is an agreement on chosen approach (I think that would make me Contributor of the project).

Now, I am not sure did I fully understand the contribution guidelines.

Since initial communication before implementing any changes has to be done, did I initiate discussion correctly here: #2264, or should I make completely new issue (and which type of issue to use in that case)?

Also, there is needs triage label, that marks issues that need to be reproduced. How to distinguish issues that need to be reproduced to ones that are successfully reproduced, but are not in development yet? Do they get their own PR, even empty one at the moment?

Thank you.

[diffy0712]

Hello,

Could you please share some updates on Typestack's plans with class-validator and class-transformer in the future?
I think these are great libraries and they should not be abandoned. If they are, than they should be marked as abandoned, so new users might not start new projects with these as dependencies.

If there are any plans, I could try to help in community work.

Thank you!

[gterras]

This issue is 15 months old and since nothing has really changed about it I think it's fair to state you've definitely moved on with your life @NoNameProvided, could you please deprecate the project or make an "looking for maintainers" announcement?

Class-transformer/validator are essential parts of the JS ecosystem and I think the current situation is holding the community back. A clear statement about the absence of dedicated maintainer would most likely help spawning a future-proof solution, especially considering the activity/popularity ratio of these repos has to be one of the lowest of the entire npm.

Right now (and since quite some time now) they are a lot of valid bugfixes/features PRs and valid issues that aren't even acknowledged. These projects should be in a better state, please don't let a great adventure rot in the corner.

@braaar you seem to bravely keep infusing minimum life support into these projects, any thoughts about this?

[olawalejuwonm]

If there are people willing to contribute we can just go ahead with V2 of the Library under same licence

…

On Sat, Mar 9, 2024, 14:56 gterras ***@***.***> wrote: This issue is 15 months old and since nothing has really changed about it I think it's fair to state you've definitely moved on with your life @NoNameProvided <https://github.com/NoNameProvided>, could you please deprecate the project or make an "looking for maintainers" announcement? Class-transformer/validator are essential parts of the JS ecosystem and I think the current situation is holding the community back. A clear statement about the absence of dedicated maintainer would most likely help spawning a future-proof solution, especially considering the activity/popularity ratio of these repos has to be one of the lowest of the entire npm. Right now (and since quite some time now) they are a lot of valid bugfixes/features PRs and valid issues that aren't even acknowledged. These projects should be in a better state, please don't let a great adventure rot in the corner. @braaar <https://github.com/braaar> you seem to bravely keep infusing minimum life support into these projects, any thoughts about this? — Reply to this email directly, view it on GitHub <#1775 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMSQ2BFQM2WYSHVLPWCA3Z3YXMIHHAVCNFSM6AAAAAAR6LHXNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWHA3DIMBQGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[braaar]

This issue is 15 months old and since nothing has really changed about it I think it's fair to state you've definitely moved on with your life @NoNameProvided, could you please deprecate the project or make an "looking for maintainers" announcement?

Class-transformer/validator are essential parts of the JS ecosystem and I think the current situation is holding the community back. A clear statement about the absence of dedicated maintainer would most likely help spawning a future-proof solution, especially considering the activity/popularity ratio of these repos has to be one of the lowest of the entire npm.

Right now (and since quite some time now) they are a lot of valid bugfixes/features PRs and valid issues that aren't even acknowledged. These projects should be in a better state, please don't let a great adventure rot in the corner.

@braaar you seem to bravely keep infusing minimum life support into these projects, any thoughts about this?

I acknowledge that this library has quite low activity considering the amount of downloads (surely due to it being a dependency of NestJS).

Since this issue was posted, me and @emir-gradient have joined the triage team (and I have gotten write access), and things have been going from very inactive to slightly active. I think we can push that needle further in the right direction by onboarding more triage team members.

[tukusejssirs]

Is there any alternative, still maintained validator library that works nicely with Nest? 🤔

[julianpoemp]

@braaar that sounds fantastic. If increasing activity to "slightly active" of this repo means that PRs are merged more frequently that would already help alot to keep this repo alive 👍

[diffy0712]

@braaar That is good news, thank you for your response.
I am mostly interested in class-transformer to start with, but I can help in class-validator too. (My projects depends on both of them, and I really don't want to replace or fork these libraries as I like them so much :) ).
I have a few hours a week to help if you can give some guidance and close issues and pr-s.

I see that there are a lot of open issues and pull requests. I think those should be addressed and develop some plan for 1.0 for both projects to have a direction.

[pknameer]

It's been months since any changes were made. Any update on the project's future?

[julianpoemp]

While this repository received updates 10 months ago, class-transformer still received no updates for the last 3 years. Even if the community made PRs they are not reviewed or merged. Even the dependency updates won't be merged. Doesn't have class-transformer any maintainers? It's very sad for class-transformer, a package with 6.9k stars on GitHub and 4.5 million downloads weekly to use deprecated dependencies, have opened bugs, open PRs for over three years...

As I pointed out in a last comment NestJS still uses class-transformer for serialization. Why does no one care about using a package that is out of maintenance for 3 years?

[braaar]

I would greatly welcome more motivated people to the team. At the end of the day, the problem is that we don't have enough people on the team who are willing and able to put in the work needed to get the project back on the path to 1.0. There is a long backlog of issues and PRs to handle and a need for a well thought out vision for what class-validator should and shouldn't be.

[ddbtrmatic]

I would greatly welcome more motivated people to the team. At the end of the day, the problem is that we don't have enough people on the team who are willing and able to put in the work needed to get the project back on the path to 1.0. There is a long backlog of issues and PRs to handle and a need for a well thought out vision for what class-validator should and shouldn't be.

The mentality of waiting for the perfect stewardship is a trap that many projects of this type fall into. Life will only get busier and the project will only become more deprecated. The current direction is dead-in-the-water, maybe somewhere at all wouldn't be so bad, even if it's not perfect.

[gterras]

I would greatly welcome more motivated people to the team. At the end of the day, the problem is that we don't have enough people on the team who are willing and able to put in the work needed to get the project back on the path to 1.0. There is a long backlog of issues and PRs to handle and a need for a well thought out vision for what class-validator should and shouldn't be.

The mentality of waiting for the perfect stewardship is a trap that many projects of this type fall into. Life will only get busier and the project will only become more deprecated. The current direction is dead-in-the-water, maybe somewhere at all wouldn't be so bad, even if it's not perfect.

I agree here, vision should probably be to merge good fixes and simple features to create stronger dynamics around the project. Happy to help for identification or review on the class-transformer side @braaar