Clarify when it is and isn't allowed to mention Powerlevel10k

[romkatv]

Please provide guidance when mentioning Powerlevel10k is OK vs not OK.

Some hypothetical situations where Powerlevel10k could be mentioned:

1. A user opens an issue that can be resolved by switching to p10k. Is it allowed to inform them of this option?
2. A user opens an issue that can only be resolved by changing their own system. For example, their config is invalid. After helping them to find a solution, is it allowed to inform them about the existence of p10k?
3. I myself open an issue describing a bug in p9k. Is it allowed to mention that the bug is fixed in p10k?

What kind of references are allowed?

1. By name.
2. Link to the project.
3. Installation instructions to try p10k.

Mentions of which projects are restricted?

1. All ZSH themes.
2. All ZSH themes that are compatible with p9k.
3. Only p10k.

What kind of statements about p10k are allowed?

1. That p10k is faster.
2. That p10k doesn't have some bug that p9k has.
3. That p10k has a feature that p9k doesn't.

Where mentions are allowed?

1. In a p9k issue opened by myself.
2. In a p9k issue opened by someone else.
3. In a p9k PR sent by a p9k team member.
4. In a p9k PR sent by an outsider.
5. On social media. (I understand that you cannot restrict me from mentioning p10k on social media but you can say that doing so will get me banned from p9k.)

Clarity should help with the tension that apparently has been building up but I've learned about the fact only today. It's your project, your rules. Whatever you decide, I'll abide by it. I'm not looking for answers to these specific questions -- whichever form your guidance will take, I'll do my best to follow.

[bhilburn]

Thanks for opening this, @romkatv. I appreciate the gesture, intent, and goal of opening this issue. I was actually planning on opening an issue on the p10k tracker to talk about these and related topics, including how we might be able to better combine efforts.

I can't actually respond to this right now (busy at my day job at the moment, etc.,), but I wanted to respond ASAP to say thanks for getting this rolling, and I'll respond as soon as I'm able =)

[bhilburn]

Hey @romkatv! Again, thanks for opening this issue. Your questions are very specific and targeted, and while I could answer each one individually, it might be better to talk about the larger picture.

Clarity should help with the tension that apparently has been building up but I've learned about the fact only today. It's your project, your rules. Whatever you decide, I'll abide by it. I'm not looking for answers to these specific questions -- whichever form your guidance will take, I'll do my best to follow.

Thanks again - I really appreciate the intention of this. Yes, there is a bit of tension, and it stems pretty much entirely from your statements that can sometimes cross the line to encouraging people that have come to our bug tracker for help to leave the project / community. To give a specific example, in #1295 you said, "you could switch to Powerlevel10k, which allows you to define your options anywhere in the configuration file. It's also much faster." There are numerous examples like this from the issue tracker over the past month or so.

As I mentioned on Twitter, your participation with p9k is confusing to me. On one hand, you have made very valuable code contributions in the form of new features, bug fixes, and performance improvements, and also are quick to provide responses to new issues. On the flip side, though, you are maintaining / building out an alternative project and seem more than happy to tell users to ditch p9k and move to it, instead. So, from my perspective, you are both contributing to the p9k project but at the same time splitting the community and competing with the project. You even have a screen cast titled p9k-vs-p10k.cast in the top-level directory of the p10k repo. Ultimately, if this continues, it will weaken p9k and end up hobbling both projects.

p10k does indeed have some fantastic features, and has re-implemented aspects of p9k is superior ways with new methodologies. Replacing the standard git-status with a custom utility that speeds things up was smart, and clearly has significant benefit, too.

In my opinion, the best way forward for both of our users, and thus the existing community, is to stop competing between the two projects and combine efforts. I really don't see any benefit to keeping them as separate efforts. We will simply end up fixing the same bugs and trying to implement the same features in two separate places, with a user community split between them.

If this is something you would be up for, let's talk about how to get it done. @dritter and @Syphdias have been working hard on hammering out the v0.7.0 release, which has been in the pipe for quite a while now. I've been using your gitstatus implemention with p9k for the last several months, and it works flawlessly. I really think true collaboration is the best option, here, moving forward.

If you would rather chat about this privately, feel free to shoot me an e-mail. Let me know what your thoughts are, and happy to chat about this more :)

[romkatv]

Yes, there is a bit of tension, and it stems pretty much entirely from your statements that can sometimes cross the line to encouraging people that have come to our bug tracker for help to leave the project / community. To give a specific example, in #1295 you said, "you could switch to Powerlevel10k, which allows you to define your options anywhere in the configuration file. It's also much faster." There are numerous examples like this from the issue tracker over the past month or so.

Thank you for providing a specific example where references to Powerlevel10k were inappropriate. Perhaps we can derive more general guidance from it.

From my point of view, the progress on the issue went as follows:

1. The user has defined all p9k options after sourcing the theme. p9k respects most options defined this way but not all. In this specific case the user expected POWERLEVEL9K_MODE=nerdfont-complete to take effect but it didn't.
2. I told the user that they can fix the problem by moving POWERLEVEL9K_MODE=nerdfont-complete to the top of the config file.
3. I told the user that alternatively they can replace powerlevel9k with powerlevel10k in their ~/.zpreztorc, which should not only fix the original issue but also make their prompt faster.

From my point of view, (3) contained potentially helpful information for the user. It's a simpler change than (2) and it brings additional benefits. It doesn't result in any meaningful way in shutting this person out of the p9k community or depriving the community of the benefit of their presence. It keeps the door open for going back to p9k should they be dissatisfied with p10k in the future.

The last paragraph is subjective. I'm describing my own thought process and opinion without expecting you to agree. My goal here is attempt to show what kind of guidance w.r.t. p10k references will or won't be effective. "It's not allowed to inform issue reporters about the existence of p10k" would have prevented my mentioning p10k on https://github.com/bhilburn/powerlevel9k/issues/1295. "All suggested resolutions on issues must be made in the best interest of p9k users" wouldn't. My comments on https://github.com/bhilburn/powerlevel9k/issues/1295 may seem in violation of the second rule to you but not to me. This makes the rule ineffective and is bound to produce tension.

I'm respectfully asking for guidance that I can follow without causing grief to p9k developers. While no rule can be exact, please bear in mind that you and I will be interpreting it from very different standpoints. For the guidance to be effective, it needs to be reasonably specific and unambiguous. I won't question your reasoning for the restrictions or even ask for justification. Since p9k already has a code of conduct, my preference would be to extend it with an extra clause.

In my opinion, the best way forward for both of our users, and thus the existing community, is to stop competing between the two projects and combine efforts.

How do you see this happening? Could you give an example of a combined effort we could undertake that would benefit users of p9k and p10k?

P.S.

On one hand, you have made very valuable code contributions in the form of new features, bug fixes, and performance improvements, and also are quick to provide responses to new issues.

I'm not sure if I'm reading this statement correctly but to stay on the safe side I should clarify that I haven't sent any PRs to p9k. This comment has no [Collaborator] label next to my name.

[bhilburn]

Thanks for the thorough response, @romkatv. It's really helpful to get a better understanding of your perspective & thought process, and I appreciate that you're thinking about the fact that the existing p9k devs will interpret it differently.

In my opinion, the best way forward for both of our users, and thus the existing community, is to stop competing between the two projects and combine efforts. How do you see this happening? Could you give an example of a combined effort we could undertake that would benefit users of p9k and p10k?

From my perspective, p9k and p10k have the same goals (really, this is pretty much a given since p10k is a fork of the codebase). So, why not actually really combine efforts? p9k has a userbase somewhere in the 250k range, give or take, and continues to grow. I think the best way for us to build the best project with the broadest impact is to not have two separate projects.

Would you be up for coming onboard p9k as a dev instead of developing in p10k? If you're up for it, we can talk about the exact code path with @dritter, @Syphdias, and others, but immediate steps can be integrating your gitstatus into p9k more directly for the v0.7.0 release, getting that released ASAP, and then migrating over your other improvements for v0.7.1. And, going forward, obviously new work would happen in p9k directly. If our goal is to upstream your improvements from p10k into p9k, anyway, I see no benefit to them being separate projects to begin with.

Anyway, let me know what your thoughts are on the above!

[romkatv]

The feasibility of merging p10k into p9k and the timescale on which it can be done depends on the state of the projects. p10k can be described as a p9k fork with integrated gitstatus and a few other improvements. Alternatively it can be seen as an independent project with a different code base, priorities, development methodology and culture. The truth lies somewhere in between these two points of view. Similarly, p9k can be seen as thriving or stagnating.

Assuming the left extreme on both spectra leads us to the conclusion that merging p10k into p9k is feasible within a short time frame. There isn't much code to merge. The development capacity and velocity of p9k team is large enough to make merging affordable.

On the other extreme we have to tackle the immense challenge of reconciling two independent projects and creating a blend. This has to be done with scarce development resources that are already strained. The prospect of success is bleak.

You seem to favor the first assessment. While I don't subscribe to the second, my estimation of the state of p10k and p9k is different from yours. Perhaps p9k devs can chime in with specific feasibility and timeline estimations for merging p10k into p9k.

Unless p10k completely disappears in a reasonably short amount of time, we all will benefit from specific guidance on when it is and isn't allowed to mention p10k. I implore you to address my request. We can continue the discussion about merging p10k into p9k after that. Otherwise there is a significant risk of preserving the status quo for the foreseeable future, along with undue tension and grief.

[Syphdias]

Just FYI, I follow this thread closely but currently, I don't think I can contribute much to the discussion. I think the points you make, @romkatv, are all valid. I gave my thoughts to @bhilburn and @dritter directly. But in the end, it's Ben's decision.

[dritter]

For me it boils down to your intention. If you want users to try out your branch in order to get a specific problem fixed, you need to communicate that for sure. But if you do not want to get your features/fixes merged then it feels odd to me to point to another repository. A fork is - more or less - another project, if there is no intention to get this code upstreamed.

I agree, we never made that clear in the Code of Conduct, yet it was obvious to me. I would guess that every project would consider it rather rude, if you would point to another project there..

Furthermore I second Bens encouragement you to merge (at least some parts) of P10K in P9K. But I see that you are moving way faster than we can (at least me).

This is of course only my point of view, and not an official statement. Strange enough that I feel the urge to say this (but I think I have to).

[romkatv]

For me it boils down to your intention.

This criterion can lead to finger-pointing and accusations of bad faith. If I declare that my intention is to merge p10k into p9k, does it give me license to tell p9k users to try p10k? If I did that, would you object that my declaration wasn't a proof of having the intention to merge? What if I demonstrated that my intention was genuine by giving sworn testimony and taking a polygraph test but still didn't send you any patches, would it then be OK? I suppose not. It's not the intention that matters.

I agree, we never made that clear in the Code of Conduct, yet it was obvious to me. I would guess that every project would consider it rather rude, if you would point to another project there. [...] Strange enough that I feel the urge to say this (but I think I have to).

Thank you! Cultural differences lead to communication issues when everyone assumes that obvious truths are obvious.

The example of an open source substitute product that comes to my mind is from C++. GCC and clang are two C++ compilers that are mostly drop-in replacements for each other. They even have the same command line flags to make switching between them easier. Their bug trackers have thousands of cross references. I never thought it rude to mention in my GCC bug reports how clang handles the same code, or the other way around. This information is valuable to users who bump into the same bugs and to the developers of both projects.

Different communities have different customs. That's why we have explicit Code of Conduct. I suppose every statement in the Powerlevel9k Code of Conduct is obvious common sense to you and yet this document exists.

I'm sounding like a broken record when I repeat my plea to add one more obvious common sense truth to the Code of Conduct that would prevent the type of messaging I've been engaging in that you find rude and Ben finds insulting. I'm not questioning your judgement or challenging your opinion. All I'm asking for is a bit of clarity.

Furthermore I second Bens encouragement you to merge (at least some parts) of P10K in P9K. But I see that you are moving way faster than we can (at least me).

We all may wish to merge p10k into p9k but there is no recipe for converting wishes into code. p9k and p10k have dramatically different architecture. How do you envision the path of convergence?

[bhilburn]

@romkatv - Sorry for the long delay in responding to you, here. I've had a number of conversations with a bunch of different folks about lots of different p9k topics, this one included.

So, as you pointed out in this thread, one of the biggest differences between p9k and your fork, p10k, is the development philosophy. I think you're right - the way you want to go about p10k development just doesn't fit with the approach and method of p9k. Even if we completely upstreamed everything you've done into p9k, I suspect you would be frustrated trying to develop directly within the p9k flow.

So, here's my proposal:

1. We don't try to fully upstream p10k.
2. We do try to pull in changes & improvements from p10k where we can and where they make sense.

Obviously, p10k is your project and you can do whatever you like. But, it would be great if p9k could continue to benefit from your development and expertise.

In terms of your original question regarding when to mention p10k, I don't want to go through each of your specific questions and give a specific binary answer, because it will be impossible to cover every scenario - I think it's not useful.

So, here is what I think is a good rule of thumb: It is okay to mention p10k in the context of improving p9k, e.g., "I fixed this bug in p10k and am working on upstreaming it to p9k." If it's not within the context if improving / making p9k better, though, I think it's best if you refrain. Based on this thread, I think that's the safest way forward.

[romkatv]

the way you want to go about p10k development just doesn't fit with the approach and method of p9k. Even if we completely upstreamed everything you've done into p9k, I suspect you would be frustrated trying to develop directly within the p9k flow.

We are on the same page. Frustration due to development impedance mismatch would go both ways.

We don't try to fully upstream p10k. We do try to pull in changes & improvements from p10k where we can and where they make sense.

Feel free to pull anything you like as long as it's compliant with the license. Attribution in commit and PR descriptions would be nice but not required. I'm not going to be sending PRs myself. If you want to incorporate improvements from p10k, you get the driver's seat. If you tag me on issues, PRs or code reviews, I'll do my best to answer your questions and share opinion.

It is okay to mention p10k in the context of improving p9k, e.g., "I fixed this bug in p10k and am working on upstreaming it to p9k." If it's not within the context if improving / making p9k better, though, I think it's best if you refrain. Based on this thread, I think that's the safest way forward.

Thank you, this is clear enough.

As I don't plan to be sending PRs to p9k, I won't be able to say in good conscience that I am working on upstreaming a bug fix or a feature to p9k. This makes it even easier for me to follow your guidance. From now on, I won't be mentioning p10k on any official p9k communication channels outside of the context where p10k is already a subject of the conversation. As of today, I believe this covers https://github.com/bhilburn/powerlevel9k and https://gitter.im/bhilburn/powerlevel9k. Let me know if I've missed some channels that should also be protected from p10k mentions.

[bhilburn]

Feel free to pull anything you like as long as it's compliant with the license. Attribution in commit and PR descriptions would be nice but not required. I'm not going to be sending PRs myself. If you want to incorporate improvements from p10k, you get the driver's seat. If you tag me on issues, PRs or code reviews, I'll do my best to answer your questions and share opinion.

We will 💯 give attribution. That is required by the license, but even if it wasn't, we would do that anyway. Your insight & guidance would for sure be appreciated.

As I don't plan to be sending PRs to p9k, I won't be able to say in good conscience that I am working on upstreaming a bug fix or a feature to p9k. This makes it even easier for me to follow your guidance. From now on, I won't be mentioning p10k on any official p9k communication channels outside of the context where p10k is already a subject of the conversation. As of today, I believe this covers https://github.com/bhilburn/powerlevel9k and https://gitter.im/bhilburn/powerlevel9k. Let me know if I've missed some channels that should also be protected from p10k mentions.

Nope, that's pretty much it.

I will say, though, that if you recommend porting over or are giving insight / help in pulling over something from p10k, I would consider that "working on upstreaming". i.e., If we start a PR effort or file an issue to bring something over and you are helping, I think that more than passes for you helping.

I'm going to close this out since I think we're all in agreement, here. Thanks for opening this, @romkatv, and being open to the discussion :)

[romkatv]

I will say, though, that if you recommend porting over or are giving insight / help in pulling over something from p10k, I would consider that "working on upstreaming". i.e., If we start a PR effort or file an issue to bring something over and you are helping, I think that more than passes for you helping.

Sounds good :+1:

I'm going to close this out since I think we're all in agreement, here.

Yep, I think is issue is resolved. Thanks.