Organization

[quote=“iamntz”]Here is a crazy idea: why not give admin permission to Jon on existing organization? This way, he will still have issues gathered in one place, no need to do any migration or whatever.

[/quote]

That would mix community packages with default packages and I wouldn’t want that. Instead, I would rather rename the old organization (to something like “SublimeTextCommunity”) and allow Jon to register a new org under the name “SublimeText”. I’m not sure if github properly sets up redirects for the old urls in this case, but I suppose it does.

Jon, if you would like this to happen, please contact me or Guillermo. (We should think of a process of notifying current SublimeText org team members of this change, preferrably before the rename.)

Existing DefaultPackages issues repository

For the “issues” issue I posted github.com/SublimeTextIssues/Core/issues/892 two days ago, which proposes to move the DefaultPackages repository under Jon’s control and then letting him force-push his repo over our few Markdown documents. Problem with that: We would lose issue access and could not manage it anymore, unless Jon adds us as contributers, which currently includes write access to the whole repo (not sure if he would want that).

One Repo per language

Regarding one repository per language, I think there is a serious flaw in that concept: Default packages depend on one another, notably HTML and family. Since these dependencies are not linear (i.e. there is no hierarchial structure, all are on the same level), once can not simply move them to submodules without breaking otherwise atomic commits.

Otherwise I agree that splitting is more convenient for projects that stand on their own (own issues, easy to fork/clone, ability to promote different contributors for selected packages).

Maybe someone knows a solution for this?

No license

Another concern I have about the repo currently is that there is no lincese.