Define the goals of this fork

[paulmelnikow]

When this project was created, @nicouaj made this suggestion in #26:

Clearly define what are the project goals (maintenance only, new features ?)


I’m opening this ticket as a place to discuss the project goals. This discussion will help determine how we – that's @facastagnini, @johnpneumann, and I, to start – maintain the project, and the direction it takes.

We want to hear from you: users, module developers, and other stakeholders.

Here are a few questions to think about:

1. What should be the goals of this project?
2. By what principles should it be maintained?
3. How should we coordinate with other projects?
4. How can this project help grow the zsh ecosystem as a whole?

[belak]

I think this is definitely a good thing. I'm a huge fan of zprezto, but it could definitely be better maintained.

1. I've always viewed zprezto as a simpler version of oh-my-zsh (which makes sense because that's what it was initially started as). There was a blog post a while back by robbyrussell about how OMZ grew and it links to an issue where there was discussion about simplifying OMZ and a comment by soren explaining why his fork (which eventually became zprezto, as far as I know) was worthwhile (https://github.com/robbyrussell/oh-my-zsh/issues/377#issuecomment-4431619). Many of the goals and frustrations expressed in that thread are probably similar or the same now. I think they can mostly be summed up into: provide a nice bundle of built-in plugins but don't become everything and the kitchen sink. I would like to see new features as well as bug fixes, but that may just be me. It's also hard to draw a line where you'll get useful new features but won't end up with 5000 plugins.

2. Maybe it's just me but this question seems a little vague? I'd like to make sure that there's not just one person at the head, as both OMZ and the current zprezto fork are very lightly maintained or not maintained at all... that tends to happen when there's only one person at the head.

3. Stuff like antigen (or similar plugin managers) comes to mind. There are a number which I assume have the original repo location hard coded. It would probably be best (once this project has grown to the point where it can "officially"-ish take over from the old repo) to get these plugin managers to point here to avoid as much confusion.

4. I've always liked the idea of having a bundle of plugins for people to pull from (and other people seem to as well as seen in OMZ, Spacemacs, and other bundles) and a way to easily configure which bundles are enabled or disabled. Having a simple way to configure and maintain a config and a way to just "enable support for X" is really nice. Having a simple way to configure zsh and add powerful support for common languages (and perhaps some less common ones) makes it much easier to introduce people to zsh and get them set up with a productive setup without having to worry too much about learning every single little option.

[malikoth]

I don't know about questions 3 or 4. Here are my initial thoughts on 1 and 2.

What I want out of Prezto is embodied in the expression, "Make common things easy, and rare things possible." In line with that, I don't see any problem with adding some new features, as long as they are simple, well structured, and have high value / popularity. For instance, I think the docker contributions from akarzim in #49 are a good fit for being part of the prezto core, because Docker seems to be very common now. However, adding a million modules for every niche command would be overkill. I very much like the idea presented in #52 to integrate with another plugin manager (go zplug!). It makes it so we don't NEED Prezto to contain a bunch of specialized commands, and it makes the integration of such into an individual user's configuration possible.

One thing that Sorin said that made me sad was how antagonistic he was towards novice users. (https://github.com/sorin-ionescu/prezto/issues/231) tombh said:

"the current README does not support people that have an existing .zshrc"

To that, Sorin replied:

"I understand. I just haven't cared because I've tried to keep Prezto away from people who don't know how to fix that issue. I have found it a useful barrier against people who would turn Prezto into the Wild Wild West Oh-My-Zsh is. They execute the instructions in the README. Prezto does not work. They go back to Oh-My-Zsh."

I think we can do better than that. Where this is now a community project with multiple contributors, I don't think keeping novice users off of the issue list should be a project goal. I think we should make it as simple and painless to install as possible.

This leads me to my biggest problem with zprezto as it exists today. It was designed to be forked by every user, modified, committed, and user configuration stored alongside the code that runs the configuration framework in the user's fork. I'd rather have the framework code which is maintained by the author(s) separate from my configuration which is maintained by me. I'd like to be able to look at what differentiates MY configuration from the default by looking at what's in my repo, not by combing through all of the project files looking for my changes. So I'd like for the prezto initialization step to source a user file (arbitrarily named and documented, or taken from the environment, or something) or just provide a single file that the user's own .zshrc would source to kick everything off.

So here are my goals for zsh-users/prezto:

1. Fix all bugs
2. Make it work well for all users (even beginners)
3. Separate the configuration framework from a user's own configuration
4. Add new features if they are deemed common ("Make common things easy")
5. Get plugin management done ASAP ("Make rare things possible")

[jeffcox]

I think we can do better than that. Where this is now a community project with multiple contributors, I don't think keeping novice users off of the issue list should be a project goal.

I don't think Prezto is necessarily unkind to novice users, but it is certainly not coddling them.

I think we should make it as simple and painless to install as possible.

How much additional complexity would this require? Is gaining users a noble goal?

It was designed to be forked by every user, modified, committed, and user configuration stored alongside the code that runs the configuration framework in the user's fork.

I think this approach was the soul of Prezto. Dotfiles and shell environments are inherently personal, and trying to make them all encompassing will always result in bloated projects like oh-my-zsh. There's nothing wrong with the approach, or oh-my-zsh; but as a Prezto user the thing that keeps me happy is only needing to merge upstream every now and then and trust there won't be a lot of bloat coming in.

[malikoth]

I think we should make it as simple and painless to install as possible.

How much additional complexity would this require?

I don't think it would take much. If there's any support for it, I'll make a PR and submit it.

Is gaining users a noble goal?

I don't care if it's noble. It's a goal I have for Prezto, regardless. The question is if the community shares my view. :)

as a Prezto user the thing that keeps me happy is only needing to merge upstream every now and then and trust there won't be a lot of bloat coming in.

I agree with this 100%. I don't see this as being mutually exclusive with having my configuration stored separate from Prezto.

[malikoth]

The question is if the community shares my view. :)

Perhaps that's not the question at all. Perhaps the question is really, "Is gaining users a worthwhile goal?" Sorin's perspective seems to be that gaining users leads to the wild wild west, and that's a bad thing. I think that with well-defined project goals (See #44) to help differentiate between what kinds of PRs will and will not be accepted, and an active and involved community, we will be able to avert the PR-hell of OMZ. On the upside, more users will be able to vet the existing codebase, fix bugs, shore up the problem spots in the code, etc. Basically, I think that yes, more users would be a good thing for the long-term viability of this fork.

[crivotz]

I am agree about all points with @malikot. Thanks

[sorin-ionescu]

@malikoth Keeping novice users off the issue list was a project goal. Hence why I provided no installer. Oh-My-Zsh serves them well.

[johnpneumann]

FWIW when I started using zsh, I used a plain version for a week and then tried oh-my-zsh (that lasted 2 days) and switched to Prezto after that. I had been an avid bash user for 12 years before that, but I don't think that there's a necessity to have an install script as everyones configuration will differ. How I setup my configuration will differ from everyone else and I think that the installation is fairly straightforward. And man zsh is everyones friend.

[malikoth]

@sorin-ionescu Nice to see you active! I've been wondering if you'd come pop in and say hi. :)

Keeping novice users off the issue list was a project goal. Hence why I provided no installer. Oh-My-Zsh serves them well.

I understand that, and it makes sense. My assumption has been that Prezto has actually gotten so much popularity that you've gotten burned out on maintaining it, leading to your recent radio silence. If that assumption is true, it would give even more validity to your rationale.

My only point is that I feel that it is possible to have a sustainable, maintainable project sans the old west, while being more inclusive and friendly towards new users. Perhaps I'm wrong, in which case, I hope my ideas don't screw up this fork! My sole desire here is for Prezto to be as good as it can be. I can only voice my ideas and see how the community responds to them. I think there is good discussion going on, so I'm feeling good about that respect. :)

[sorin-ionescu]

I didn't get burned out. Prezto was not a priority this past year since it became good enough. A lot of pull-requests are only used by the user, not the community at large, but the user is dead set on having his module or theme merged. I want a voting system.

Homebrew got wild, but the maintainers restored the sanity of the project. The same can be done for any popular project.

My preferred merge method is to rebase or cherry-pick since this kind of project tends to create a hell of a log graph. It requires advanced Git knowledge compared to pressing a green button on GitHub.

I want to add maintainers that would enforce pull-request standards, e.g., coding style and commit message language—it's pendantic, but none of us are paid gibberish linguists at Illiterate State University.

[johnpneumann]

@sorin-ionescu - Agree on the merge methods, however are the other bits documented or should it simply be obvious based on the current code structure, etc. ("Illiterate State University" killed me).

Also, @paulmelnikow and I have been talking and are wondering what the best way moving forward is from this point. Given that your codebase is the source of all of this (and we don't want to fracture both effort and users), should this project "go back to the mud" and we can continue whatever work/dialogue/etc on the main repo or ... something else that's clever sounding that I can't quite think of right now? My time and interactions have been limited, but I'd like to contribute in some way as I use Prezto for 14-18 hours of my day.

[paulmelnikow]

Good discussion in this thread! @sorin-ionescu, great to hear from you. I’m glad there’s a path open for adding maintainers. 👍

Like many people I’ve used Prezto for a while without following the project too closely, so I discovered the fork by accident. In the two weeks since I joined as maintainer I’ve combed through old PRs, current issues, and lots of old discussions. I’m glad there’s a path open for adding maintainers to the original. Some of the work I did here will be helpful like this triage of the open PRs and a few things that have been fixed here.

It’s evident from studying the commit history of the fork that the graph is hard to follow without a straight-line history and careful commit messages. Certainly agreed about coding standards too.

In terms of novice users: I do think their usage questions are better answered via Gitter than the issue tracker. These questions tend to involve a lot of back and forth, which rarely is useful to anyone other than the original poster. There are some exceptions to this: #27 would help a first-time user who googled the error message.

That said, being inclusive and friendly is important. New contributors need to feel welcome, people using Prezto for the first time, and contributors who aren't native English speakers.

I disagree that keeping novice users off the issues list should be a project goal. I like how @malikoth put it:

... it is possible to have a sustainable, maintainable project sans the old west, while being more inclusive and friendly towards new users.

As @johnpneumann alluded, I don’t see much benefit in pushing forward on a community fork given Sorin is willing to add maintainers.

[paulmelnikow]

To clarify,

1. I don’t see much benefit in pushing forward on a community fork given Sorin is willing to add maintainers.
2. Let's put reviewing and merging changes on pause while this is sorted out. This avoids duplicated work, and confusion about the fact that un-forking is expected to be imminent.
3. Sorin has said a straight-line commit history and clear commit messages are important. That means bringing up to standard and rebasing the work that's been done here.
4. People install Prezto using git. Doing a rebase on zsh-users/prezto/master would be confusing.
5. There are many GitHub comment threads linking to this repo. Replacing it would be confusing and would break those links. It makes more sense to wind this down and post a instructions here directing people back to the main repo.

@sorin-ionescu what's the best way for people to contact you if they want to be maintainers? Email, comment on sorin-ionescu/prezto#1239, or open a new issue?

[nicoulaj]

+1

Alternatively, there is one way that will not break any link:

• Pull changes from this repo into sorin's one
• Delete this repo
• Transfer sorin's repo to the organization

Github setups redirections when transferring a repo.

2017-03-17 20:42 GMT+01:00 Paul Melnikow notifications@github.com:

To clarify,

1. I don’t see much benefit in pushing forward on a community fork given Sorin is willing to add maintainers.
2. Let's put reviewing and merging changes on pause while this is sorted out. This avoids duplicated work, and confusion about the fact that un-forking is expected to be imminent.
3. Sorin has said a straight-line commit history and clear commit messages are important. That means bringing up to standard and rebasing the work that's been done here.
4. People install Prezto using git. Doing a rebase on zsh-users/prezto/master would be confusing.
5. There are many GitHub comment threads linking to this repo. Replacing it would be confusing and would break those links. It makes more sense to wind this down and post a instructions here directing people back to the main repo.

@sorin-ionescu https://github.com/sorin-ionescu what's the best way for people to contact you if they want to be maintainers? Email, comment on sorin-ionescu/prezto#1239 https://github.com/sorin-ionescu/prezto/issues/1239, or open a new issue?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zsh-users/prezto/issues/44#issuecomment-287452636, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAMWhVMITAYPc2WSsGwaA8sM7VUN7h7ks5rmuIKgaJpZM4MTK8I .

[belak]

I'd love to help out with reviewing PRs and helping to improve the existing modules (and perhaps rarely adding new ones).

I'd like to avoid being limited by one or two people if at all possible. There are quite a few projects which go mostly unmaintained because people end up waiting on a maintainer that isn't around very often (see oh-my-zsh and the 600+ pull requests). Is the plan to add more general maintainers which would deal with the whole package or with maintainers of the modules themselves?

[belak]

In terms of new modules, my personal preference would be to see a proposal issue opened before a large PR appears asking for a new module to be merged. I'm not a huge fan of modules which add tons of aliases without much else and it would be nice to see useful functionality added rather than smaller shortcuts.

And in terms of old modules, if new functionality is added, it would be nice if it didn't break/change old functionality unless needed. I've seen quite a few theme changes which completely change how that prompt looks... but many of these would be possible if they were added as options rather than replacing existing functionality.

[paulmelnikow]

Alternatively, there is one way that will not break any link:

Not sure this is true.

• Pull changes from this repo into sorin's one
• Delete this repo
• Transfer sorin's repo to the organization

It would cause confusion and merge conflicts for users who are tracking this branch, who will see zsh-users/prezto/master as if it's been rebased. The reason is, the changes made here won't be merged, they'll be re-reviewed, brought up to quality, and rebased.

It would also cause us to lose the record of these discussions. We should keep it around. 😄 Renaming this repo from zsh-users/prezto to zsh-users/prezto-community-fork would address that, though once Sorin's repo is moved in its place, links to these discussions from outside (e.g. from other projects) will break.

[maximbaz]

Nothing new has been merged in Sorin's repo for over a year, there won't be any duplicate work if you guys keep maintaining this project - let's have at least one alive prezto!

Deleting any of the repos is a bad idea, as both projects have open issues - you will just lose them. The best way is to ask Github folks to merge the projects - keep the code of this one, move all issues from sorin-ionescu/prezto to zsh-users/prezto, and make sorin-ionescu/prezto redirect to zsh-users/prezto. I have already seen Github helping with moving projects like that.

If Sorin's approval is required for any of these actions, just drop him an email, do not rely on Github notifications.

[jrolfs]

tldr; I'd love to see Prezto maintained and curated with new modules only being added as deemed very important/ubiquitous while focusing on maintaining the core codebase and existing modules. I use zplug (insert your favorite zsh plugin manager here) to add functionality that is more specific to my needs.

Update: I think Docker is a good example of something that would make sense incorporating as a core Prezto module

---

I was referred here after opening #36 as you can see above. I also came across #52 and I think my feedback regarding the direction of Prezto in general kind of belongs in both threads so I'll go ahead and leave my two cents here.

I originally came across Prezto as an Oh My Zsh user and made the decision to switch very quickly. Although I read a bit about the improved performance of Prezto, my reason for switching really hinged on the overall architecture of the project. After scanning through the code a bit, even as a somewhat novice-level shell developer, it was immediately clear that Prezto was a well thought out, well documented, well structured and clean "configuration framework".

I hadn't really put a ton of thought of it until now, but it's clear that a big reason that Prezto has those characteristics is not only due @sorin-ionescu's thoughtful initial implementation, but also the curation of the project to maintain simplicity. I'd love to see this continue, but clearly that's really what this thread is all about.

I have since implemented Prezto within zplug. However, I did it in a way that ensures Prezto still stands as the core of my configuration because I like the conventions it defines which really help my configuration stay understandable and have a stable core foundation.

With zplug I can now add functionality that I specifically need: some plugins from Oh My Zsh, some that more or less stand on there own as "zsh plugins" and some things that are completely custom or of my own making. I still rely on Prezto to handle core zsh configuration and I use all of the Prezto modules that fit my needs.

I would love to see Prezto continue to be maintained, however my humble opinion is that new modules should only be added to Prezto itself if they really are ubiquitous system shell tools. I know that's still a rather blurry line, but I'd rather see the existing modules improved and maintained as technologies change rather than add more modules.

I really like the idea of having a sort of rough standard of a standalone "zsh plugin" that can be loaded via zplug or any of the other plugin managers that now exist as they all seem to be fairly flexible/agnostic in supporting modular add-ons. However, I don't want to give up Prezto as my base configuration.

Hopefully that makes some sense despite being very vague and maybe even helps you maintainers guide the project a bit more. I really want to see it stick around in the community :)

Here's a direct link to my (zplug) .zshrc: https://github.com/jrolfs/dot/blob/master/home/.zshrc Shell dot files repo root: https://github.com/jrolfs/dot

As you can see, I still very much use the Prezto 'runcoms' for convention/structure.

[sorin-ionescu]

Post collaborator (maintainer) requests at https://github.com/sorin-ionescu/prezto/issues/1269.

[sorin-ionescu]

There are pull-requests of obscure modules and themes that are only used by the author.

If a module does not benefit many people, it should not be merged. Aliases need to be checked for collision.

Derivative themes that change very little, e.g., colors, should not be merged because the prompt function takes arguments allowing for theme configuration; thus, non-configurable themes should be made configurable.

[rjcoelho]

Should merge and close this fork since sorin-ionescu/prezto is active again ?

[nicoulaj]

Yes. When do I delete the fork?

[paulmelnikow]

I'm glad things are moving upstream! Agreed this project has served its purpose.

Instead of deleting it, could you update the description to "DEPRECATED FORK" or similar, and set the URL to point to Sorin's repo? #63 is open to add a big fat notice to the readme.

The repo serves as a historical record of what happened here, and a reference to the discussions and testing that happened around patches, bug fixes, etc.

[nicoulaj]

No, sorry, but I don't want an abandonned fork in zsh-users. So it will be deleted, or transferred to another account.

[paulmelnikow]

Hmm. Well, that's your prerogative. I could make a new organization.

[belak]

I guess once we've got most of the fixes ported back over, this probably wouldn't need to exist... I'm not sure of everything that was merged in here though, so there may still be some fixes that need to be ported.

[paulmelnikow]

I don't want to see the issue and PR discussions deleted. Deleting project's history isn't a good idea, especially if it can just be moved out of the way. Moving it out would clear the way to move Sorin's here.

Plus, I don't think you'll want to merge all the changes, and it'll mean you can finish addressing them over time, even if Sorin's repo gets moved right away. I offered in sorin-ionescu/prezto#1279 to go through them, and I'm still willing to do that.

[nicoulaj]

So which account/org do I transfer the repo to ? I will delete the repo at the end of the month otherwise.

[paulmelnikow]

@nicoulaj I created https://github.com/prezto-inactive-community-fork and invited you, along with @facastagnini and @johnpneumann.

With that name, there should be zero confusion, which is my aim.

[nicoulaj]

ok, done

[jasonmp85]

FWIW it might be nice to push some sort of commit that issues a warning for each new shell about this fork being dead. GitHub transparently redirects I guess, so I'd been git fetch-ing for a while now wondering why no new commits were coming in.