Consider moving the package to JuliaArrays for greater visibility

[juliohm]

I am using this package in Meshes.jl to handle polygonal geometries that create loops. I wonder if you would be willing to migrate the package to the JuliaArrays organization for greater visibility and maintenance reasons? It is nice to have multiple people working on a fundamental package like this to make sure it is up-to-date and following all the latest tricks.

[juliohm]

@Vexatos what do you think of this?

[Vexatos]

I'm not sure about this. I'll think about it and just leave this issue open for now as a reminder. Thank you for choosing to use my package, though.

[cocoa1231]

I think it would be great. This package should get more attention, it's really useful

[juliohm]

@Vexatos did you have a chance to reconsider this? As you can see from the number of stars in the issue, the community would benefit from an increased list of maintainers to hot fix and release new patches.

[Vexatos]

For now, I'd like to keep it to myself. For a small project like this, I prefer keeping full control over it, making sure the scope stays limited so that no unnecessary things are added, and not having to answer to anyone if I ever do decide to make changes. It also helps with keeping the code clean.
If I ever end up losing motivation to maintain it, I'll certainly accept the offer, as others are using the package now.

[juliohm]

@Vexatos the fact that there are 6 PRs opened, and you are the only person with write access is a bit concerning. It is fine to keep this package as a personal project, but we appreciate if you can signal that to the community.

We will fork the package if you prefer to keep CircularArrays.jl to yourself, and will maintain a separate package in JuliaArrays or another org where contributors can discuss alternative designs and new features. We are constantly bumping into design limitations with the current implementation, and cannot fix things quickly.

[Vexatos]

I'll maintain my position that I'd like to keep this project to myself. I want to make sure this package remains generic and keeps compatibility with all custom array types I may encounter, and importantly, I need it to retain its high efficiency, which is best ensured through a small codebase. The package might not do everything you want it to do just yet, so I greatly appreciate any and all contributions to this package. However, some things you want are probably better suited for either a higher-level package based on this, or an entirely different implementation altogether.
I try to review pull requests whenever I have time. Recently, reviews had been scarce owing to me not having much free time. It is nice knowing that other people use this small package for their own work, but I will not mindlessly accept any and all features people would like to add to it. If the review process is not fast enough for you, or if there is something you want to have in the array type that I would not be comfortable having in my package, and that cannot be added in a higher-level package depending on this, there is nothing wrong with making your own implementation. I'm simply not a fan of small generic packages getting overloaded with barely related features over time, to the point where I wouldn't be able to use them for my own projects anymore.