Document purpose of organization and/or repo

[docwhat]

I would suggest that we document the purpose of the organization and/or just this repo.

The I WANT TO HELP readme is a good start though it is mainly a broad "this happened and I had to take emergency action".

The information I'd be interested is:

• Can we expect bug fixes once things settle down?
• Can we expect security fixes?
• How about new features?
• Or even evolve into new things?

For example, the whole flag'value' thing (instead of --flag=value, while technically cool, is very non-standard and hinders adoption. Even if the feature is kept, the docs should probably shift to the (also supported) long-opt format (--flag=value).

[pschmitt]

Agreed, we most definitely need to extend the disclaimer. I'm not entirely sure about how to word things in this regard. All suggestions are welcome.

As to whether bug fixes are to be expected: the answer is yes. I for once spent quite a bit of time already on getting the pack ice to somewhat work again. A whole lot of people helped us revive the deleted repos.
If there's anything that needs fixing we will absolutely look into it. Just open an issue or ask in discussions.
I built my whole cli workflow around zinit so the incentive to fix whatever needs fixing is there (and I'm for sure not the only one).

Can we expect security fixes?

Same as above.

How about new features?
Or even evolve into new things?

Sure, why not. I'm already thinking about implementing an if-arch ice for example.

For example, the whole flag'value' thing (instead of --flag=value, while technically cool, is very non-standard and hinders adoption. Even if the feature is kept, the docs should probably shift to the (also supported) long-opt format (--flag=value).

That's debatable, zinit has always been doing it's own thing but we absolutely can discuss such changes (zparseopts ftw). Maybe in another issue though 😉

zinit is not going anywhere. @psprint 's amazing work will live on :)

[docwhat]

That's debatable, zinit has always been doing it's own thing but we absolutely can discuss such changes (zparseopts ftw). Maybe in another issue though 😉

I wasn't trying to address that change here; I'm not even sure I want to make that change. It was an example of a fairly big evolution that would never have gone into zdharma/zinit.

[docwhat]

Agreed, we most definitely need to extend the disclaimer. I'm not entirely sure about how to word things in this regard. All suggestions are welcome.

Yeah, I'll have to cogitate on a mission statement kind of thing. Especially since I want it be couched in positive language and I'm still cheesed off. 😛

[alichtman]

+1 to (almost) everything @pschmitt said above.

I built my whole cli workflow around zinit so the incentive to fix whatever needs fixing is there (and I'm for sure not the only one).

Same here. zinit is an integral part of my shell workflow (because it's way faster than any of its competitors). I personally can't commit to any support for development, HOWEVER, this organization is a reliable home for the project and will be maintained responsibly. Note that I've granted @pschmitt maintainer privileges, so the bus factor is > 1.

For example, the whole flag'value' thing (instead of --flag=value, while technically cool, is very non-standard and hinders adoption. Even if the feature is kept, the docs should probably shift to the (also supported) long-opt format (--flag=value).

Yeah, this irks me too :) Totally in favor of standardizing it (obv requires a longer discussion though)

[alichtman]

We also need to standardize on a synchronous discussion platform. I set up Gitter: https://gitter.im/zdharma-continuum/community?utm_source=share-link&utm_medium=link&utm_campaign=share-link

Here's an embeddable Markdown button: [![Gitter](https://badges.gitter.im/zdharma-continuum/community.svg)](https://gitter.im/zdharma-continuum/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)