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

RFC: Propose migration to preservim namespace #651

Closed
alerque opened this issue Aug 31, 2020 · 9 comments
Closed

RFC: Propose migration to preservim namespace #651

alerque opened this issue Aug 31, 2020 · 9 comments
Assignees
Labels

Comments

@alerque
Copy link
Member

alerque commented Aug 31, 2020

Close to a year ago when @majutsushi put out a call for maintainers (cf. #549) and I volunteered, I also proposed moving the project under the auspices of a new org namespace I had just started specifically to house vim plugins that were popular but being maintained by someone other than their original owners. At the time my own involvement in Tagbar was unproven and the org idea was completely new — so I understand completely why Jan opted not to go that route and kept the project in his personal namespace.

However I'd like to float the proposal again and ask for a re-evaluation. Conditions have changed somewhat in the intervening ~11 months. Since I was added as a collaborator I think I've demonstrated how I would run the project so it shouldn't be such a scary experiment. Even after working through the initial backlog of PRs and merging everything that was ready and fixing many that weren't I've continued to help many new contributors that have come along since get their PRs ship-shape and merged. I've also worked through the issue list triaging, commenting, closing, and generally moving the project forward.

While a year ago I didn't –and currently still don't– have any grandiose plans of sinking a bunch of development time into new features myself I think the track record confirms that under my watch as maintainer outstanding issues do gradually get cleaned up and anybody that does come along with good code will be able to contribute it into the project relatively easily.

On the org side, after proposing it for this project @preservim did become the new home for the nerdcommenter and nerdtree plugins. The former is primarily maintained by myself (since 2016) in much the same way as my work on Tagbar, and the latter is primarily maintained by @PhilRunninger. To my knowledge there haven't been any issues at all from Phil's side of things. I think the umbrella of @preservim has been a good generic home for those plugins where both the original authors are recognized and credited as well as being neutral enough for active maintainers to have some ownership of the project while still being welcoming to other contributors.

Somewhat ironically in my 4 years with nerdcommenter and 1 year with this project the only objections raised to my management of either project that have come up involved the same dissenter, @wsdjeg — who was also appointed as a collaborator at the same time I was on this project. Although they are mostly resolved I never fully understood the reasons for the objections and don't know for sure if he feels like they were resolved.

For others reference: Besides objecting to the namespace migration of nerdcommenter 3 years after I became the maintainer (see comments on both #549 and nerdcommenter №400) he also later took issue with my decision to re-license (WTFPL→CC0, comments starting here). The sum total of all issues he's been involved with on Tagbar can be reviewed here. Other than this GitHub namespace issue I don't see that we have disagreed here, but he also hasn't contributed even one commit to either project and only minimally to issue comments. @wsdjeg If you still object I am more that happy to discuss, but please do more than just object: please detail specifically in what way you think this transfer would be bad for the project. As I've mentioned before the issues of search and existing links & Git forks are quite well covered by GitHub's automatic redirection process. This went 100% smoothly for both the other plugins and I expect it will be a non-issue for this one as well. Also for the record know that I'm 100% on board with the ideas you proposed for future development a year ago and would be happy to see either or both of those integrated into the plugin if somebody does the coding. I have no objection to you contributing either, my only concern is that to date you haven't contributed at all and you've objected without explaining yourself to a couple of my decisions. Hence why I'm asking that if you still disagree on this issue as you did a year ago you explain specifically why you think my proposal would be bad for the project.

As for the advantages I see in migration:

  1. I would like more access to the repository settings. Currently I have no access at all, but I would like to be able to do things like protect the master branch, setup the existing CI jobs as required checks on PRs, and if necessary configure any more tests we can get working that prove whether proposed changes break anything or not before allowing merges.

  2. I would like to be able to invite people that have made substantial contributions as collaborators at least with limited permissions. GitHub has nice granular tools for this so that at least others could help some with issue triage directly and even merge PRs (with for example a requirement of one review approval). When people are contributing anyway and doing so in clearly positive ways giving them a little control usually helps motivate more of the same. Also it would help keep the whole project responsive so that it doesn't get held up during periods where I am not as available. There have been weeks and months already where things waited on me to have time for open source work.

  3. The somewhat more neutral space I think would better reflect the de facto status quo as far as being @majutsushi's creation but now community maintained.

Given that the scope of my involvement with Tagbar is almost identical to nerdcommenter and my proposal is to manage it the same way, I don't think there is any advantage to starting yet another namespace and there is something to be gained from having similar projects grouped together.

Ergo my proposal:

  • Transfer this canonical repository to @preservim.
  • Once there, mark @majutsushi and myself as project owners so that either of us have control over project settings and granting permissions to other contributors.

Jan while obviously this is a call for community comment as well, at the end of the day this is largely up to you to decide. If you are favorable to the proposal you have an open invite to @preservim (invitation only last 7 days, I just renewed yours from last year but can do so again if it elapses) where I'll make sure you get listed as owner of this project still; but also know that if you still are not convinced that's okay, my plan B is to just keep calm and carry on here as in over the past year. You decide.

@alerque alerque pinned this issue Aug 31, 2020
@majutsushi
Copy link
Collaborator

I think this sounds very reasonable. From what I've seen you've done a great job maintaining the project. If I remember correctly we originally decided to not move the project for now just so we don't do everything at once and because we didn't know if it would really be necessary. I think it makes perfect sense though to be able to easily give more people limited permissions as co-maintainers, and that seems to be easiest with an organization. So as far as I'm concerned I would be happy to move the project to an organization.

@alerque
Copy link
Member Author

alerque commented Sep 1, 2020

Okay. I'm actually traveling most of this week so lets leave this open for comment until I get back, then if there are no reasoned objections we can throw the switch next week. I don't think there will be any issues, but on the principle of "don't push to production on a Friday", its probably smart not to do anything just before traveling either.

@majutsushi
Copy link
Collaborator

Sounds good to me!

@wsdjeg
Copy link

wsdjeg commented Sep 5, 2020

I am ok. Thanks for support this plugin.

@alerque
Copy link
Member Author

alerque commented Sep 9, 2020

@majutsushi I think we're good to go on this, transfer trigger is in your hands.

@majutsushi
Copy link
Collaborator

Okay, I've initiated the transfer. I'm not sure if there's anything left to do for you to finish it.

@alerque
Copy link
Member Author

alerque commented Sep 13, 2020

Awesome.

I don't think there is much else to do. I'll start poking at CI and other config stuff, but the migration is done. Redirects seem to work already so most people won't notice, even when updating their plugins over Git.

One thing I should mention is that –to the best of my knowledge– it's now important that you @majutsushi do not fork this repository back to your personal namespace. If you do that, I think the redirect system goes away and people will start landing on your fork instead of the canonical repo. It will take a very long time (years? decades?) for people to notice and update the plugin configs in their RC files. Instead since you still have full access to the repository here (you are an Admin for this repo which means you can still do whatever including administer collaborators, transfer it out somewhere else, etc.) just do anything you do on this repository directly: i.e. for you dev work should be done on a branch here rather than experimenting in your own fork. This doesn't apply to anybody else (I'm free to keep and muck around in my fork at alerque/tagbar), but because the redirects from the old namespace are dependent on there no longer being a repo in your personal namespace for the foreseeable future it would be better to keep the redirects.

@alerque
Copy link
Member Author

alerque commented Sep 13, 2020

@wsdjeg If you see messages about "removed permissions" don't panic, I'm not trying to leave you out! I did drop your write permissions but only from the "outside collaborator" list and only to shuffle where the permissions are managed from individual accounts to a "tagbar-contributors" team. I've sent you an invite to the org and also and to that team specifically. The team should have the same write permissions you had before. No obligation to accept of course, but if you're interested in participating know that the offer to continue is open. I just shuffled around which GitHub mechanism was granting permissions to make it easier to audit and manage.

@alerque
Copy link
Member Author

alerque commented Sep 13, 2020

@raven42 I also invited you to the org & team with permissions on this repository. Of course there is no obligation to accept if you're not interested, but noticing that your were the most active recent contributor and that your contributions were solid was part of what reminded me that I'd wanted to get this moved into an org where permissions could be shared a little more.


I've also changed the repository settings such that the master branch is now protected and requires that PRs pass CI checks and have one review approval from any other collaborator before merger.

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