Decide on official criteria for new modules

[belak]

There's been some disagreement lately around what would actually be "good enough" for a new module... in terms of popularity, content, and size. I don't know if there's a "correct" answer, so it would just be good to get everyone's opinions and try to form some sort of consensus.

Firstly, popularity. We've tried a few things in the past (measuring language statistics, asking for a certain number of likes, etc) but most of this criteria is somewhat subjective.

Next, content. Do we want to allow modules which are all aliases (as an example) or are we requiring something more substantial? Maybe some configuration and aliases?

And finally, size. This is closely related with content, but not quite the same. Do we want to put a minimum (or maximum) size on new modules, to make sure we don't get 100 modules which all do very small things.

What does everyone think? Do you think those are decent criteria? How would we go about quantifying those? Are there any other criteria which you think would be better (or would work in addition to these)?

[jeffcox]

I think it would make the most sense to keep prezto lightweight and instead direct people to a separate "modules" project which could be more accepting. This would keep the base install reasonable while encouraging and centralizing modifications.

[belak]

There was a bit of discussion in #1411 (and specifically, I'd like to mention https://github.com/sorin-ionescu/prezto/pull/1411#issuecomment-321683521)

I've already sent @nicoulaj a message about hosting it under the zsh-users project and he seemed open to it as long as we have an identified set of leaders and we can promise it won't be a temporary project like last time.

[johnpneumann]

So my opinion on this is the same as what @jeffcox stated, however, since "lean" was brought up, I'm going to (do what apparently is my favorite thing at this point and) quote @sorin-ionescu, because I believe the relevance to the questions is there:

I will not limit collaborators as long as they remain true to the project by not turning into something it is not. I expect collaborators to continue the work in the same manner it has been done, for it is the reason why we are all here.

Prezto must remain lean.

To provide additional context, rather than just quotes, I'll give a summation of my thoughts (which generally means it'll be long, wordy and you'll fall asleep halfway through, so enjoy).

• Unless it is believed to benefit 80% of the community, it should not be merged. To determine how we'd gauge that, we'd need to track users and we're not going to do that. So it will always be something somewhat subjective. Even something as universal as git (the irony of posting this on here is not lost on me) is only used by a certain userbase. Can we say with a level of certainty that 80% of people using prezto are using git. Yes. I'm fairly certain we can put that at 100% (even if it's only so they could pull it down, though I genuinely can't imagine doing that). I think there needs to be additional discussion around this in particular, because without data, you cannot make an informed decision. Maybe an anonymous survey of some sort where we just ask for what modules people are loading would suffice. I'm not sure how I feel about that, but I know that when other OSS projects ask for my usage info in a survey, I willingly give it (especially given that my benefit is generally greater than the time I spend on the survey).

• People can setup their own aliases fairly easily and utilizing others is easily done as well, so I don't think this is something we want to support.

• I don't know that size can be a requirement. I've seen bash/python/c# (oh linq) one-liners that made my life easier. However, I'm not sure that it's going to be something that we'll see within this context. As unlikely as that is, I think that the content is more important than the length.

In regards to having a separate repository under zsh-users, I'm very much in favor of that. Before we do that, we need to make sure that we have a very good set of documents that are in-place that show folks how to utilize the additional modules and we need it to be airtight. We also need to do extensive testing on this, so if there are users that would be interested in helping with the testing, that'd be great. I'm not sure how @brunomcustodio feels about things, but I, personally, would like his involvement with the testing and getting his module within that repository, when we have things sown up.

I do wonder if some of this falls into the same vein as the .local discussion (https://github.com/sorin-ionescu/prezto/pull/1346). I also wonder if it's necessary to have an entirely new repository to host new modules or if we can provide good documentation, have a folder within this repository called external-modules (or something like that) that holds all of the documentation as well as a list of repositories with the external modules. This does two things:

1. It takes the burden off of everyone from maintaining a separate repository and managing the PR's there as well as here.
2. It also allows people to discover new users that they may not have found since they'll be using their work directly, which may lead to them finding more things they've written that are useful.

IMO, I think the latter part is the larger benefit as I've personally found things from others based on simple bits here and there and have continued to follow their work over the years.

Would like to hear what others thoughts are as well. @indrajitr @jeffwidman @facastagnini

[jeffcox]

What about documenting and encouraging the use of git submodules? A zprezto module could be created as a simple repo and added as an external much the way completion and autosuggestions are handled.

[belak]

I'll do my best to sum up my thoughts here since there are quite a few good ideas going around.

• An additional repo should be created (I like the name prezto-contrib but that's definitely not final)
• That repo would have all the current contributors added (We'd start @indrajitr @jeffwidman @facastagnini @johnpneumann @sorin-ionescu and myself - and any other current prezto maintainers I missed) as long as they're interested with the option to add more later. We would look for a certain level of quality contributions to the contrib repo to be added as a contributor there.
• The modules which would stay in prezto-core are the ones where a core contributor is willing to support and maintain it. This avoids the argument about how "popular" a module is. This may not be specific enough, as there are some modules which would be maintained by a core contributor which shouldn't be in the core, but should simplify that discussion.
• Most modules would be accepted into the contrib repo unless there's a very good reason not to
• The contrib repo would follow the same code conventions as the core repo
• It would be preferable but not required for maintainers of contrib modules to stay around to maintain their modules. Preferably, each module would have an explicit maintainer who would be in charge of it, along with core contributors.
• There needs to be a defined way to load modules from the contrib repo. Maybe there should be a setting for additional prezto module dirs. I'm not 100% sure how to do this, but I'd like to have it built into the core without needing to build anything as complicated as a plugin manager and I'd like it to be as seamless as possible.

I have mixed opinions on recommending modules from lots of different places. I agree that the exposure would be good and it would somewhat reduce maintenance, but if the maintainer for that module leave, we would have to switch to a fork rather than just updating the code... plus it creates differences in expectations between modules. Different maintainers may have completely different opinions about what should go in. I could be convinced either way on this.

@jeffcox I'd like to avoid submodules in this capacity because for every external submodule, we'd need to update it each time there's an update externally... and if someone does a git clone --recursive they could potentially clone quite a few repos they don't actually want.

Also please keep in mind that these are my opinions about what I'd like to see and not a final decision.

[bmcustodio]

@johnpneumann thanks for bringing my name about, I appreciate that. However, and for a number of reasons, I am not willing to continue this discussion any further and so I am muting the thread.

[diraol]

Trying to contribute. =)

I'll do my best to sum up my thoughts here since there are quite a few good ideas going around.

You did a good job @belak!

An additional repo should be created (I like the name prezto-contrib but that's definitely not final)

It seems reasonable to me. Other possible options would be:

• prezto-extras
• prezto-extra-modules

The modules which would stay in prezto-core are the ones where a core contributor is willing to support and maintain it. This avoids the argument about how "popular" a module is. This may not be specific enough, as there are some modules which would be maintained by a core contributor which shouldn't be in the core, but should simplify that discussion.

This seems to be pretty fair too, but I think that "if these core contributors seems reasonable to keep it as a core module, otherwise they can go to the contrib module" can be added to the "criteria". It may not be related to a "popularity" criteria, but may be some of the core developers want to maintain a module that is very specific (for a very very small group, or even for some specific contexts). In that cases it may make sense to keep it outside of the core-prezto in order to keep it as smaller/cleaner as it can be.

I have mixed opinions on recommending modules from lots of different places. I agree that the exposure would be good and it would somewhat reduce maintenance, but if the maintainer for that module leave, we would have to switch to a fork rather than just updating the code... plus it creates differences in expectations between modules. Different maintainers may have completely different opinions about what should go in. I could be convinced either way on this.

This is a really really good point in favor of keeping these "extra modules" under the control of prezto core team. Moreover, it would make prezto users' life much easier in order to find these modules [and don't require a wiki page or something like that to track prezto modules around the world].

There needs to be a defined way to load modules from the contrib repo. Maybe there should be a setting for additional prezto module dirs. I'm not 100% sure how to do this, but I'd like to have it built into the core without needing to build anything as complicated as a plugin manager and I'd like it to be as seamless as possible. @jeffcox I'd like to avoid submodules in this capacity because for every external submodule, we'd need to update it each time there's an update externally... and if someone does a git clone --recursive they could potentially clone quite a few repos they don't actually want.

Considering both points above, a possible approach would be to have a directory not tracked by prezto git (.zpresto/modules/external/) in which we can sparsely clone/checkout the modules from the prezto-contrib repo. This may be done by a prezto "function" (almost a simplified plugin manager just to clone/checkout) or we can have a page with instructions on how to do it. There would also be a "helper function" to "git pull" these "modules". At last but not least, to enable the plugins we can have a config in zprestorc, such as an array for prezto-contribs.

I hope I've helped with something. ;) Cheers!

[johnpneumann]

@belak - I like the idea of prezto-contrib and I think your points about people falling off etc are valid and keeping things tight and in-line with what is required of a core module in terms of consistency, makes a lot of sense.

I think at this point it's time for some POC work to see what works, what doesn't and what can be improved. I think that seeing things in action and how it works is better than pontificating over it, especially given that I think this is further reaching than a simple repository and those things will become pretty apparent quickly and we can kinda adjust from there. Thoughts?

[jeffwidman]

From a reliability standpoint, to me a contrib repo implicitly has a more relaxed reliability guarantee. If that's true, it's probably something we should be explicit about.

Obviously we don't try to have broken code, but just let users know that contrib is less tested/used and may occasionally break and, at least for me personally, I'm not going to be as worried about immediately patching bugs in contrib modules that offer slightly more esoteric functionality such as supporting Haskell. Versus if it were a heavily used module that sits in core like the Python module, I'd be quick to jump on that.