Message to the community

[andreynering]

Hi everybody 👋

Once in a while, people ask me why the development is slow, questions got unanswered, bug reports are not responded, features not added, PRs not reviewed, etc.

The answer is simple: the project has grown to become bigger than I ever expected. With a full time job and a life outside work, I have limited time to dedicate to this project. More demand is generated from users than I could keep up even if I doubled the time I dedicate to this project.

So first of all I'd like to ask for your patience and understanding.

Secondly, I'd like to hear opinions and ideas on how to keep the project moving.

And lastly, I'ld like to ask for some help. I had two other people with write access to the repo in the past, but they quickly lost interest in the project. Other than that short period, I've being alone. You could help:

1. Answering questions, validating bug reports, giving opinions on feature requests, closing issues/PRs when they do not make sense, etc.
2. Writing code and reviewing pull requests, specially bug fixes and small features. (I'd still like to have the final word on bigger features as sometimes people suggest changes that breaks backward compatibility or add more complexity than desired)
3. Some people have helped the project by contributing to mvdan/sh as well, and I'm thankful for that. Help on mvdan/sh#93 in particular would hugely benefit Windows users if you're interested to help.

[kerma]

I've been using and advocating Task for some time now, so I'd be happy to help out as much as my time allows. For starters I could take couple of issues and submit PR's for those in order for you to validate my thinking about things. Once those those look OK I'd be happy to take on the things you listed above.

If that sounds fine, let me know which ones you'd like me to tackle first.

(EDIT: I'm not on Windows unfortunately, so cannot help much with mvdan/sh)

[andreynering]

@kerma Thanks!

My idea is not to push specific issues... usually people are more productive doing what will have more impact on their own use of the tool (features and bug fixes they want). But if you want a hint, this one should be an easy start, for example: #612.

And just to clarify, it's not necessary to be on Windows to contribute to mvdan/sh or advance on mvdan/sh#93, it's just that Windows users will be more interested on it 🙂

[kerma]

@andreynering got it. Pushed a fix for #612 as well.

As a general suggestion I think you should limit label usage by issue creators. I went through some of them and many labeled as bug are more like questions on usage and some feature requests are wild ideas which are better to be resolved with more complex examples on "how to do X". Without properly triaging issues it makes a bit too difficult for outsiders to figure what is what.

There are also a lot of open issues which seem to be solved or somewhat solved a while ago. It would be helpful if you'd take the time to go them through and close as much as possible. Or delegate (:

[andreynering]

As a general suggestion I think you should limit label usage by issue creators. I went through some of them and many labeled as bug are more like questions on usage and some feature requests are wild ideas which are better to be resolved with more complex examples on "how to do X". Without properly triaging issues it makes a bit too difficult for outsiders to figure what is what.

This is a good point. Basically I did an experiment by using issue templates to try to force issues on being either a feature request or a bug, and directing the user to open a discussion for questions, etc.

That not always work, so I just removed the automatic labeling of issues for a manual triage again.

There are also a lot of open issues which seem to be solved or somewhat solved a while ago. It would be helpful if you'd take the time to go them through and close as much as possible. Or delegate (:

Also a good point. I try to do that once in a while, but between interactions we usually have several open issues. People sometimes get upset when I close their favorite feature request, so actually I have more of them opened than I really wanted to.

Regarding "delegation", I'm willing to accept help with that. I could surely add the proper permissions for someone willing to help with that.

[kerma]

@andreynering please do add me some. I'd like to keep an eye on incoming issue reports for starters. I'll try to reproduce where I can and/or add labels.

[andreynering]

@kerma Invite sent! Once accepted I'll give you the proper permissions

[marco-m]

Hello @andreynering!

the most important message I want to give you is that being in your situation seems to be a normal phase for open source authors, and that you have my complete understanding and support. Your life and your satisfaction come before anything else! You have already given Task to the world, you don't owe anything to anybody.

My armchair opinion is that, as you wrote, you should at least keep an overall guide of the project (as long as you enjoy doing it), to keep Task true to itself and not become a kitchen sink of ideas. Often people have a reaction that each feature request and each PR should be accepted, while it is actually the opposite.

For what is worth, you have my support to close any issue and PR that, in your own opinion, are not a good fit for the project. It is impossible to satisfy everybody, and attempting to do so generates a kitchen sink.

If you don't know it already, you might find this helpful: https://opensource.guide/best-practices/

[andreynering]

@marco-m I skimmed that article and it seems very interesting. I'll read it fully once I have the time. Thanks! 🙂

[tylermmorton]

Hi @andreynering 👋

I was introduced to Task early last year and I'm now using and advocating for it on all my personal and professional projects. Thank you for the amazing tool and your dedication to the project. I'd love to help where I can with the time that I have. I can also keep an eye on incoming issues and help implement features however I'm not much help on Windows platforms.

My idea is not to push specific issues... usually people are more productive doing what will have more impact on their own use of the tool (features and bug fixes they want).

I was inspired by this so I opened PR #656 in response to #390.

[andreynering]

Hi @tylermmorton,

Thanks for the words!

I'd love to help where I can with the time that I have. I can also keep an eye on incoming issues and help implement features however I'm not much help on Windows platforms.

I just sent you an invite so you can label and close/re-open issues. Welcome aboard!

Don't feel the pressure to answer or implement those you don't have the context about. You can answer those you feel you can help and let the others to me, no problem!

I was inspired by this so I opened PR #656 in response to #390.

That's nice! I'll review once I can (may take some days).

[tylermmorton]

Awesome, thanks @andreynering! I've been going through the issue list and trying to wrap my head around the things the community seems to be itching for in terms of new features for Task. To me it seems like there's 4 main categories of focus in addition to general upkeep and bug fixes:

"Improved CLI" (logging, formatting, styling, prompts and timestamps)

• Improved Logging with Glamour #543
• Grouped output with GitHub Actions friendly begin/end markers #647
• Timestamps Needed #629
• Unable to see the task progress during execution #611
• A warning/confirm field that shows a confirm prompt before proceeding  #100

Additional features around includes:

Some non breaking, I'm happy to take ownership over these after getting some experience with #656

• Add option to 'flatten' included taskfiles #273
• Legitimate use-case of multi-level includes #390
• Feature: Allow reading dir and/or entrypoint from env #402
• Add posibility to include by dotenv #582
• Inherit all/some tasks from included file #572
• Have task attempt to fallback to a Taskfile.dist.yml if Taskfile.yml does not exist #498

Test "hooks"

• New feature: action on error #141
• Add task pre and post operations (before, after) #344
• Add a "setup:" setting to allow running setup scripts before any command? #204

Integrations, expanding the toolset

• Watch: Add optional integration with Watchman? #373
• Add remote execution via SSH? #377
• feat: add linting and/or formatting check adherence to styleguide conventions #265
• Consider use as an external library #121

So my question is, is there a plan or roadmap for the future of Task and what issues we'd like to prioritize and address? My thoughts are if we can get the priorities into writing it will be easier for us to organize and move the project forward.

[marco-m]

I give my 2 cents for a non-glamorous category: fixing bugs or non-uniform behavior of Task.

@tylermmorton note that if you edit the list you just made and replace each URL with just the number prefixed by a # sign, you should get automatic link and issue names when overing on each of them.
For example #546 -> #546

[tylermmorton]

I give my 2 cents for a non-glamorous category: fixing bugs or non-uniform behavior of Task.

Absolutely, and I think that's something we should also take into consideration when planning for the future of Task. Is the project in a stable enough position to even focus on new features? Or should we instead turn our attention towards sorting out these bugs, writing more documentation and attracting more maintainers? Is there a happy medium? :)

FWIW there's 16 issues labeled as bug ... some of them seem to be for older versions of Task anyways. Maybe a cleanup is in order

[andreynering]

Is the project in a stable enough position to even focus on new features? Or should we instead turn our attention towards sorting out these bugs, writing more documentation and attracting more maintainers? Is there a happy medium? :)

@tylermmorton I've been avoiding implementing big features in the past times, focusing more on small feature and general improvements / bug fixes.

Not that we couldn't make bigger features: we can certainly discuss those and consider carefully (Docker support seems interesting by the way). But there's a higher cost on doing it, more discussion involved and we need to consider the future maintenance of these features (everything, once shipped, needs to be maintained). So, smaller improvements has been my priority.

[ghostsquad]

@andreynering I'd be interested in getting involved in this project. I have absolutely fallen in love with this project, and have been advocating for it's use over nearly all other tools, Make, Mage, even replacing things like the npm scripts in package.json.

I'm still technically a maintainer of https://github.com/andygrunwald/go-jira but, with a significant reduction in my need for that library as of recently, I've sat on the sidelines. At the very least I helped bring in a few more maintainers to that project (kept it alive), and introduced them to https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis which I believe made a significant difference in that project's ability to make the codebase more flexible with fewer backwards incompatible changes.

If you are still looking for another maintainer, I'm interested.

[andreynering]

Hey @ghostsquad, just sent you an invite to join the GitHub organization. Welcome aboard! 😄

[ghostsquad]

Thanks for the invite @andreynering what are the next steps?

[andreynering]

Hi @ghostsquad,

I saw that you already started responding to some issues, as @kerma and @tylermmorton also did. Thanks! That's a big help for me, because answering every issue is time consuming, and splitting that work between us certainly reduce that load, and possibly means each of us can also work a bit more with code.

With regard to responding to issues and reviewing pull requests, it's fine to only take action on those you know how to proceed (the easy ones). Some would need my input and you could just ping me or do nothing and I'll look once I have the time.

Regarding possible new features, I always welcomed feedback, so you can also propose possible improvements if you have any in mind. If you are interested in implementing any of the open issues you can ask my opinion if you feel it isn't clear that we really want to do that, but only if you feel like doing it.

---

I'd like to emphasize that every help is important, no matter how small. Don't worry about doing "too little". 🙂

We've been focusing more on stability on the past times: bug fixes and small improvements as opposed to big features, but everything is open for discussion...

[andreynering]

I think this issue completed it's purpose for now.

I unpinned it and will close it, but if anyone still has thoughts feel free to still comment.

Thanks for everyone support! ♥️