Organization and co-maintainers

[Ogeon]

Dear contributors, watchers, issue posters, question askers, star button pressers, and other excellent friends of the Palette crate,

I have been maintaining this library for about 8 years now, and I intend to keep going, so don't worry! The first commit, or rather, the first few commits were made on the 2nd of December 2015, so I'm not joking whenever I talk about old code. It's only about half a year younger than Rust 1.0, if that helps to make it feel old.

During this time, Palette has grown beyond what I could imagine when I started it, and I have been learning a lot about color management and adjacent fields along the way. It hasn't only grown in size and features, but also in the amount of users. That fact is probably the most baffling, but also humbling, to me. The fact that people out there find this library so useful is one of my core motivations, beyond my own enjoyment and curiosity. The actual numbers aren't that important, but the interactions with users and contributors, and the response I have received so far, is everything.

The fact that it keeps increasing in use (or at least downloads) and size, and gets picked up by increasingly larger projects, has made me make a couple of important decisions; to move it to a GitHub organization and to find one or more co-maintainers. And I need your help!

GitHub Organization

I haven't had any practical need for an organization so far, and the decision to create one is purely organizational (heh). There's a need for branching out into more than one repository on the horizon. Primarily to create some sort of examples oriented documentation (mentioned as a "cookbook" in other discussions), and that would likely be best kept in its own repository. That allows it to have its own automation and update cycle. Secondly, there's the question of what to do with the num module in Palette. I think it's likely to become its own crate, that is also best kept separate, unless a better alternative appears.

Having an organization will also separate it from me, as a person, which helps with potentially growing the number of people involved and also passing on the torch, if it would come to that. Hopefully not a worry, but life happens sometimes. There are other benefits with organization, such as access to the merge queue feature, that aren't as important but still helps.

What I need help with:

• Finding a name. palette-crate is my best one so far, but suggestions are welcome. Preferably not with an -rs suffix.
• If a transition to an organization is something you have been involved in before, I'm interested in tips and experiences.
• Should it have a logo? :eyes:

Let me know below if you have any suggestions, tips or thoughts.

Co-maintainers

This will probably be the largest change for me, personally, but it has to be done to reduce the dependence on me as a person. This project would likely just stall if I were unable to continue working on it for some reason. Hopefully, someone would fork it, or an alternative would pop up, but it would be nice if it could continue without me around. To help this, I would like to find one or more people who are interested in keeping it rolling, one way or another. Not for the sake of my own ego, but for the sake of those who use Palette today and in the future.

This is also going to be a question of trust. I will have to figure out who I can trust to keep the best of this project in mind, and I'm not going to hide from the fact that already being a contributor will naturally be a massive merit. Reviewing pull requests is one thing, but potentially letting someone publish releases is quite a bit more. Please, bear with me as I figure this out along the way. I will have to think about how to do this correctly.

What I need help with:

• Finding at least one person who agrees with the direction of this library, has an interest in the subject, and has at least some time to contribute to it. I'm not expecting you to drive this project, and it's of course not a lifetime commitment. I essentially don't expect you to spend more than, or as much time and effort on this as I do. That would be unfair.
• The practicalities around sharing the project. I haven't done this with the help of an organization before so tips are always welcome.

Let me know below if you would like to volunteer, or if you have any suggestions, tips or thoughts.

Closing Words

You may wonder when this change will happen. I don't know, but the organization should be created as soon as I know what to call it. Finding someone to help out is probably going to be a longer process. I will have to take things as they come and figure them out bit by bit. This issue is my attempt to set things in motion.

Thank you, everyone who have been involved so far! :heart:

Erik

[MultisampledNight]

Hi! Trying to share a few experiences regarding organizations:

• @Kethku recruited me for neovide pretty soon after I made my first PR and got a bit more involved in issues.
  • I made a few releases, but am more or less just watching from afar while trying to share expertise if needed atm since daily life keeps me busy
• https://jyn.dev/how-to-maintain-an-open-source-project/ which I recently came across reflects that
  • Frequent maintainer recruitment seems to be effective for keeping a project alive and keeping the bus factor high
• This however also resulted in a lot of currently inactive entities with effective commit and release access to the repo. Removing those implies a few problems, since
  1. These entities might come back from their dormant state when the project needs it
  2. It feels like taking away something well-earned (or I'm just too empathic to do that, idk)
  3. Discussion about this might spark conflict since it's difficult to represent this positively

Personally, I'd love to try to help out in palette or at least provide emergency support, but probably only after I got a bit more acquainted to the codebase. I might try to get more involved over the next time.

[MultisampledNight]

Sidenote: The orga switch would also be a lovely opportunity to rename the master branch to main, trunk or the like.

[Ogeon]

Right, that would indeed be nicer. It's probably not much more than some find-and-replace in scripts + a change here on GitHub. 🤔

[Ogeon]

...and thanks for sharing your experiences. It got folded away by the GitHub app, but I saw it now. I will read the link a bit later, but the points you mention are why I would like to not rush this, but at least start the conversation now. I don't want anyone to feel like they have to step in and dedicate their time just for the sake of it, for example. That's why someone who already contributes from time to time probably would be a good fit, but that has been mostly sporadic or periodic so far. The bus factor is my primary concern at the moment, so it's fine if I'm still the one who most consistently works on it. And if nobody feel like they are available, then that's how it will have to be. I'm opening the door, and that's a start. Not to say that it was ever closed!

It's not going to be a blocker for the organization, either way.

[Kirk-Fox]

I know that I'm a very new contributor, but color spaces, color transforms, and display technology are all very compelling topics for me and I hope to continue contributing to and improving this library. I hope to eventually learn enough to implement things like HDR. Thank you for all the work you have put into this project and I hope to keep contributing!