You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.)
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.
The text was updated successfully, but these errors were encountered: