Project Maintenance Discussion

[azerupi]

Since last year, due to other projects, interests and scholar obligations, I have less and less time to maintain this project. I initially started this project to familiar myself with Rust and I think I achieved that goal. I now have different interests where I want to invest some time in. Therefore, I don't have the bandwidth anymore to maintain this project. In the last months, a lot of people have shown interest in this project and have contributed. I appreciate that a lot! But at this point, I feel like I can't devote enough time to review issues and PRs within a time frame that I still consider to be respectful to the persons that contribute.

I don't want to block progress and leave contributors hanging, so I think it is time that I pass over the role of main maintainer to one or more interested persons.

@steveklabnik @budziq @frewsxcv @Michael-F-Bryan

[steveklabnik]

Thank you for making this, and putting in all this work over such a long period of time! <3

I'm happy to at least help, but can't devote a ton of time; mostly working on stuff that's relevant to the features we use for the books in the rust distribution.

Given that we do use this internally, I wonder what the libs team would think about moving it to the nursery.

[Michael-F-Bryan]

Thanks for everything you've done so far @azerupi! This has turned out to be a massively useful project and even now I use it all the time for documentation or writing up little guides on the side :)

I'm happy to put my hand up as a maintainer. Although it may also be a good idea to have two or three core maintainers to help share the load and increase the bus factor a bit.

[budziq]

Thanks for this awesome project and all the help you have given the community!
Recently I'm finding myself with little free time to work on my Open Source commitments so taking on full maintainership here might be detrimental to the project 😞. But I'll try to help out some more especially in the areas relevant to rust-cookbook.

I second Steve on puling the repo to rust-lang-nursery, this is a very important project for the rust community which makes writing high quality and consistent guides a breeze. Moving mdBook there would get more eyes and hands working on the project.

[Michael-F-Bryan]

@steveklabnik, do you know what would be required to move mdbook to the nursery?

[budziq]

do you know what would be required to move mdbook to the nursery?

From purely technical point. @azerupi Will have to initiate the transfer to rust-lang-nursery account and one of the org members will have to accept.

From the logistics point of view I'm guessing that Steve will discuss the issue with libs team if they are interested in accepting the ownership.

[steveklabnik]

Yes, that's correct. I actually even have permissions over there, IIRC, so it's really just the social bit. I'm travelling right now so it's a bit complicated for me, but should be able to find out in the next week or so.

…

On Thu, Nov 9, 2017 at 10:16 AM, Michał Budzyński ***@***.***> wrote: do you know what would be required to move mdbook to the nursery? From purely technical point. @azerupi <https://github.com/azerupi> Will have to initiate the transfer to rust-lang-nursery account and one of the org members will have to accept. From the logistics point of view I'm guessing that Steve will discuss the issue with libs team if they are interested in accepting the ownership. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/azerupi/mdBook/issues/482#issuecomment-343185968>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsiiPd1i_7MyXeJ7dfee7PfLpgyt9Mks5s0xdngaJpZM4QTZVQ> .

[azerupi]

Given that we do use this internally, I wonder what the libs team would think about moving it to the nursery.

That would be awesome, I would be honored. :)
When you have more information about that, let me know so that I transfer the repository. In the mean time, @Michael-F-Bryan I will add you as a maintainer!

[Michael-F-Bryan]

In the mean time, @Michael-F-Bryan I will add you as a maintainer!

Awesome! In the meantime I've got a couple hours to kill so I might start doing a couple code reviews. I'm in the same boat as @budziq though in that I'm more of a systems-level programmer than a front-end dev.

[steveklabnik]

I've gotten the green light to transfer it; feel free to initiate whenever you have time, @azerupi !

Basically, it will be similar to rustdoc: committers to mdbook will be "tool peers" under the devtools/doc team. :)

[Michael-F-Bryan]

Basically, it will be similar to rustdoc: committers to mdbook will be "tool peers" under the devtools/doc team. :)

Just out of curiosity, what is a "tool peer"?

[steveklabnik]

It's something slightly less than "team member", that is, you're a team member for that tool rather than for the team as a whole. It's jargon specific to the dev-tools team.

[budziq]

Basically you retain the collaborator/commit rights to the repo

[Michael-F-Bryan]

you're a team member for that tool rather than for the team as a whole

Sounds good to me 👍

I guess the big question is... How will this affect the project from an organisational/logistical standpoint?

As it stands I really like what this project does and have a couple core features I'd like to see incorporated in some day (e.g. alternate backends and plugins), so I'm more than happy to keep helping out.

[steveklabnik]

I guess the big question is... How will this affect the project from an organisational/logistical standpoint?

Basically, those of us who are maintainers operate on rough consensus. It feels to me like mdbook already works that way, so it shouldn't be a big change. The other difference is that the URL to the repo changes. That's about it though.

[budziq]

have a couple core features I'd like to see incorporated in some day

Yeah some of your PR's are long overdue for final review and merging. Probably will need to get more focus on reducing that backlog.

As long as we don't introduce regressions I'm game with any new features.
Lets stick to some minimal discussion prior to merging significant changes and we'll do just fine 👍

[azerupi]

@steveklabnik I tried to transfer it to rust-lang-nursery but it failed because I don't have the permissions to create a repository on that organization. So I think it's best that I first transfer the repo under your name so that you can transfer it to the organization? :)

[steveklabnik]

Sure thing!

[azerupi]

Damn, looks like I can't do that either because it already exists (as a fork) 😅
I think you first need to delete your fork before I can transfer the repo. GitHub makes this way more complicated than it should be... 😋

[steveklabnik]

Deleted!

[azerupi]

Done! Thanks a lot :)

[steveklabnik]

Boom! https://github.com/rust-lang-nursery/mdbook

[azerupi]

Excellent!
I suppose we need to setup Travis, Appveyor and GitHub pages again for the new repo?

[steveklabnik]

I'm not sure; given that you had permissions with the old repo.... here, let me open a PR and we'll see!

#484

[Michael-F-Bryan]

Looks like someone in the rust-lang-nursery organisation will have to move appveyor across. Even though I've got commit rights to this repo it doesn't look like appveyor will let me add anything to rust-lang-nursery's builds.

cc: @rust-lang-nursery

[budziq]

Given how many hoops we had to jump through with Alex to give me permissions for cookbook appveyor (without me joining nursery org) I'd suggest to just leave appveyor where it is as long as it works and we can trigger builds.

[Michael-F-Bryan]

I was thinking it may be easier to ask someone already part of the nursery organisation to move things across, seeing as it's a one-time thing.

I'd suggest to just leave appveyor where it is as long as it works and we can trigger builds.

It doesn't look like the CI hooks are working any more because the repo's URL has changed. If you go to any recent PR and scroll to the bottom it's only firing off travis builds, meaning there's no guarantee that any changes we make work on windows.

A recent PR:

A PR from before the move:

[budziq]

Ouch! Then we need to move then. I'll try to dig up the steps we've done to allow me administrative access on cookbook appveyor (being collaborator is not enough, we'll need an additional account on appveyor)

[steveklabnik]

I'm an owner of the nursery, I can do this. I've been at conferences and on vacations so have been a bit MIA, but am back now. Likely to catch up with the huge backlog monday. If you take care of this before then, great, but if not, I'll do it then :)

…

On Sat, Nov 18, 2017 at 12:40 PM, Michał Budzyński ***@***.*** > wrote: Ouch! Then we need to move then. I'll try to dig up the steps we've done to allow me administrative access on cookbook appveyor (being collaborator is not enough, we'll need an additional account on appveyor) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#482 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsiluqjdy-pNIE1F16p2MXCXFktmdAks5s3xZ1gaJpZM4QTZVQ> .

[budziq]

If you take care
of this before then, great,

Unfortunately we will not be able to do much without nursery membership :/.
Here is a summary of what we have worked out with Alex previously. Quite a lot of gymnastics to achieve basic feature.

[Michael-F-Bryan]

@azerupi, @budziq, @steveklabnik, what do we need to make appveyor push compiled artefacts to GitHub releases? It seems like the easiest way to handle #481.

[Michael-F-Bryan]

Do you guys know anyone who'd be interested in helping on the frontend side of mdbook? Recently I noticed that a PR I'd merged introduced a regression and although it was mostly negligence on my part (I didn't test it as thoroughly as I should have), "silly" issues like that could probably be prevented if there were more eyes.

[projektir]

@Michael-F-Bryan
I worked a little bit on the frontend side, I could perhaps help with reviews.

[Michael-F-Bryan]

I've just realised that when merging #457 we should have gone to 0.1.0 instead of doing a patch release (updating book.toml largely broke the format's backwards compatibility), so I'm thinking we should do a major version bump fairly soon. Unfortunately I need pulldown-cmark to make a patch release before that can happen (pulldown-cmark/pulldown-cmark#118 (comment)).

I've also implemented most of the stuff necessary for alternate backends (#507) and am fairly confident (#507 (comment)) it's the right way to do things in the long term. If possible, I'd like to include that in any upcoming 0.1 release because it gives us a really good foundation for implementing things like plugins (e.g. pre/post processing before rendering) and alternate backends.

Does anyone have any thoughts or opinions on doing a major semver bump and including the alternate backends mechanism?

[projektir]

@Michael-F-Bryan I think a new release (as I understand a major semver bump should result in this?) is a good idea, and we could also address #481 then.

[Michael-F-Bryan]

Yeah, I really want to do another release but I'm still waiting for pulldoen_cmark to make another release (pulldown-cmark/pulldown-cmark#118 (comment)). I guess I could always make a temporary workaround so we can release, then revert it later on. Thoughts?

[Michael-F-Bryan]

We also need to get Appveyor working again so we test PRs against Windows and make sure it can do releases. It's still pointing at the old location, azerupi/mdbook, and because I'm not part of the rust-lang-nursery organisation I can't set it up again. It's a 5 minute job, I just don't have the right permissions to do it 😞

If anyone knows someone on the infra team, would you be able to CC them into this conversation?

CC: @rust-lang-nursery

[projektir]

pulldown_cmark repo looks a bit inactive to me right now... last activity was December 10th. I don't know if I want to say "work off of a fork for now", or how difficult the temporary workaround would be, but I'm not really much for waiting for other repositories without a timeline.

@steveklabnik, @Mark-Simulacrum
You know who can help setup AppVeyor for rust-lang-nursery/mdbook?

[Michael-F-Bryan]

I don't know if I want to say "work off of a fork for now",..., but I'm not really much for waiting for other repositories.

Agreed. I'll probably be able to make a PR with the workaround after work tonight.

EDIT: Done #555. I'll merge it once travis gives the all clear.

[Mark-Simulacrum]

cc @alexcrichton @aturon -- we'll probably need your help with setting up AppVeyor for this repository.

[alexcrichton]

It's now enabled

[Michael-F-Bryan]

It's now enabled

Awesome! Is there any chance you'd be able to make a PR updating the badge in the README? It seems appveyor use some sort of hash/uuid as the image URL for a project's badge instead of just the project's name.

[Michael-F-Bryan]

@alexcrichton, would you happen to have the snippet for mdbook's Appveyor badge? I just noticed we've still got the old azerupi/mdbook badge at the top of our README.

Also I don't believe we've got any Windows binaries in the releases, so we may have to update the API key for Appveyor or appveyor.yml. Anyone know the best way to do this?

[alexcrichton]

https://gist.githubusercontent.com/Zoxc/7c4a288fa4143385efcdadfd16638a75/raw/6bc6e40daaa82361643b6244dd3b69aaa37b3185/gistfile1.txt

[alexcrichton]

er,

[Michael-F-Bryan]

@steveklabnik, what's the usual process for adding people as maintainers to a rust-lang-nursery repository? After reading through the Bus Factor +1 thread on the user forums it may be beneficial to add another co-maintainer to mdbook to help share the load.

[carols10cents]

I'm going to close this given that maintainership is changing again, see #858, so I think this instance of maintainership transfer has been completed ❤️