PrettyTables.jl icon indicating copy to clipboard operation
PrettyTables.jl copied to clipboard

Published 20 hours ago • verified publisher icon ronisbr

Consider moving PrettyTables.jl to JuliaData

Open bkamins opened this issue 4 years ago • 6 comments

Since PrettyTables.jl is for Tables.jl I would move it to JuliaData. In this way we will make sure it is more discoverable and potentially gets more support (which might be needed at some point e.g. if we make it a default renderer for DataFrames.jl).

@ronisbr - what do you think about it?

CC @quinnj @nalimilan

bkamins avatar Sep 12 '20 19:09 bkamins

Hi @bkamins !

I have absolutely no objection to that! However, I am not used to those kind of organizations in GitHub. I have only one (JuliaSpace), but I am the owner. Will I have permission to change things inside the new package, like defining Actions, creating branches to store the documentation, and to setup things like Travis and Coveralls?

ronisbr avatar Sep 12 '20 19:09 ronisbr

Yes - this is a good consideration.

I think you should be added to JuliaData group (you definitely meet all conditions for inclusion). Then you would be allowed to do whatever any owner of the group is allowed.

Now what owner will be allowed to do in the package depends on how you decide to set it up (e.g. in DataFrames.jl I am not allowed to merge anything to master without approval although I have written over 75% of the code currently in this package - and I am OK with this), but I am allowed to create branches (I am not sure about Actions as we use Travis job to build and deploy documentation; Coveralls are also configured). Probably @nalimilan might know more about the administration stuff.

I would not rush with this move, but felt that it is good to put it on a table and consider pros and cons.

bkamins avatar Sep 12 '20 19:09 bkamins

I think you should be added to JuliaData group (you definitely meet all conditions for inclusion). Then you would be allowed to do whatever any owner of the group is allowed.

Good!

Now what owner will be allowed to do in the package depends on how you decide to set it up (e.g. in DataFrames.jl I am not allowed to merge anything to master without approval although I have written over 75% of the code currently in this package - and I am OK with this), but I am allowed to create branches (I am not sure about Actions as we use Travis job to build and deploy documentation; Coveralls are also configured). Probably @nalimilan might know more about the administration stuff.

Maybe in the future I can adopt a more restrictive development style to PrettyTables.jl. However, right now, the only active developer is me, so it is not possible to change.

I would not rush with this move, but felt that it is good to put it on a table and consider pros and cons.

In fact, if I can continue to develop as I am doing today, I am good to move it to JuliaData ASAP, if the other people are OK with it.

ronisbr avatar Sep 13 '20 02:09 ronisbr

Yes, this is a good idea. I've added @ronisbr as a member of JuliaData; I think that should be enough to move your repository in by yourself, but let me know if that doesn't give you enough permission. But yes, once you move the repo into JuliaData, we can ensure you have full admin/owner rights to PrettyTables.jl to still change/update anything you want.

quinnj avatar Sep 13 '20 03:09 quinnj

Perfect! Thanks @quinnj

I am about to finish the PR to add the first version of PrettyTables.jl back-end to DataFrames.jl. When I finish this, then I move the repository.

ronisbr avatar Sep 13 '20 03:09 ronisbr

However, right now, the only active developer is me, so it is not possible to change.

Exactly this is what I understand (and thank you for working on this).

bkamins avatar Sep 13 '20 06:09 bkamins