Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move DBIish to it's own Organization #84

Closed
jonathanstowe opened this issue Jan 8, 2017 · 3 comments
Closed

Move DBIish to it's own Organization #84

jonathanstowe opened this issue Jan 8, 2017 · 3 comments
Labels

Comments

@jonathanstowe
Copy link
Member

This is for discussion, if there is agreement then the only changes will be to create a new organization in github, move DBIish to it, and change the META.list entry for DBIish to point to the new repository.

DBIish is a fairly important module, it's likely that many large applications in Perl 6 will want to use it and people will want to build other modules on top of it that provide higher level abstractions to users.

Whilst it's quite happily sitting in the perl6 organization right now, this has a couple of cultural and technical drawbacks.

Firstly, and this is both technical and cultural, there may be people who want to contribute to DBIish but may be daunted by the core implication of it being in the perl6 organization and also if they are to a core contributor to DBIish then there is a barrier to giving a commit as it is inconvenient to grant a commit to just the one repository in perl6 and also they may really not want to get bogged down in all of the other stuff that comes with the organization.

Secondly, and I think this is a positive enhancement to the current situation, is that a separate "organization" can act as an incubator for further work on both new database drivers and possibly higher level abstractions: for example I think it would be fairly easy to kickstart a bunch of drivers for Informix, Sybase, Firebird etc but I'm not convinced that I would like to commit myself to their long term maintenance, having the drivers in "common maintenance" will lower the barrier to entry and possibly cause more to be written.

Finally and purely culturally making the move will demonstrate that "Database support" is all grown up and can move from under the control of its parent project.

So I'd commend doing this, and just to put my time where my mouth is would be happy to do all the work required to perform the move.

@moritz
Copy link
Contributor

moritz commented Jan 8, 2017

Moving to a separate organization increases the barrier to contribution. Getting a commit bit to the perl6 org is very easy, and there are current 240+ people with push access, which I consider a feature. All of them can contribute to DBIish easily right now. Maintaining separate permission lists is a a burden. And it's not just the list of contributors, but also the owners who can add new users etc.

So I'm slightly opposed to moving it to a separate organization.

If you consider the actual activity in DBIish, I think maintaining a whole separate organization is overkill.

@jonathanstowe
Copy link
Member Author

There are 240+ people with push access of whom about 5% have made any contribution to DBIish.

The barrier to contribution should be different to roast, docs, ecosystem, DBIsh etc depending on the needs of the particular sub-project. Managing the permissions within one organization with a clear focus is easier (and the barrier to contribution lower, given local criteria.)

@abraxxa
Copy link
Contributor

abraxxa commented Jan 8, 2017

I'd deal with that when time tells which option is better suited as I currently don't see a problem, do you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants