Maintainers & Team Structure [discussion]

I’ve been thinking that Hugo is at a point where it would really benefit from a bit more structure around the project.

We’ve got an active group of contributors and I’ve realized I’ve become a bit of a bottleneck for handling pull requests.

I’d like to make the suggestion that we adopt a bit of structure and appoint a few maintainers to be responsible for different parts of Hugo.

Currently @natefinch & @spf13 have commit access and I’d like to keep both of us as general maintainers over the project.

I’d love some volunteers to be responsible for the following pieces:

Of course a good pull request would include docs and tests with it, so these aren’t rigid lines, but rather someone who has responsibility to make them better… as well as the authority to merge things.

I’m open to any suggestions or volunteers for any other parts, or for a different approach.

Volunteers / Thoughts?

Edited to reflect current volunteers.

I’d like to help with anything not Go related (docs/templates/themes). I’m not fluent with managing a repo on Github. I’d likely need some hand holding when it comes to that.

1 Like

I think based on this thread and the work he’s done that @OwenWaller has already volunteered and is mostly doing the testing role. Also in looking at that thread he’s setting a great example of a leader helping to shepherd other efforts.

You’re not run down with volunteers; I guess most of us have selfish reasons to why we contribute: We want that missing little feature.

The current list of open pull requests are 27 items. If you group some that are tied together and ignore some old ones, there are about 10 to consider for a merge. I understand that it’s more work involved than just pushing a merge-button, but it doesn’t sound like scary much work for two persons.

Of course, if those two persons do not have ANY time to spare, even that list can seem daunting.

But do remember that many run Hugo from the latest in master branch, so it’s not a perfect situation to leave it in a broken state for longer periods, like now, esp. when there are simple fixes in the PR queue.

Obviously I’m up for looking after the testing side of this.

I agree with @bjornerik though. This all comes down to time. If we are all busy (who isn’t?) then even a tiny list of PR’s will look like a big job. One way forward might be to go for the trusted lieutenant model used by the Linux kernel, the @spf13 and @natefinch are getting overloaded.
See:
http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow

One thing we might want to look at though is simply to create a shared development branch, and keep master stable. Then when we have stable release on development to tag it all up and merge it into development. That would seem to relieve the problem @bjornerik is pointing out. This would also have the happy side effect that anyone who does a “go get …” on the hugo master repo should always get a stable version.

@michael_henderson - More than happy to help with the hand holding of git/github. I spent two days last week in work teaching my BA’s how to use it. The concepts are pretty easy to grasp, once you know that its easy. You’ll only need to know about 6 commands to be effective. It’s really not that hard.

Maybe there are people who would like to help, but are not up to “being responsible for themes”, for instance. If that’s the case, would it help to have a list of smaller pending tasks? Or can that only happen after there are “section leaders”?

@hamoid It’s a lot more manageable with section leaders.

@bjornerik
You aren’t wrong that just 10 PRs aren’t too much… But there’s a lot more to the project than just pull requests. For instance we also are responsible to triaging all issues. Managing the forum. Active feature development. Building things like the new theme showcase, helping mentor contributors, etc.

I’ve learned a few things about communities.

  1. People want to be a part of successful open source projects.
  2. Many people want to help but feel like it’s not their place to do so.
  3. If you invite people to help they feel welcome.
  4. Everyone is busy and often at different times. Being part of a group of contributors can help people feel less burdened as others can help.

My whole thoughts here is that if we can deputize a few maintainers then they can help make Hugo even better than it is today and hopefully free Nate and I up a bit to work on some of the broader things like adding new features and refactoring across the application.

@OwenWaller, you’re probably right that we could benefit from a development branch. I find this a bit odd since we do distributed a binary version of the latest “stable” release, but I guess old habits die hard and a lot of people are used to running from master. The only real difference here would be that master would be effectively frozen along with the binary release until the next binary release. It doesn’t feel like it’s accomplishing much in reality. I think the Dictator & Lieutenants workflow is overkill right now, but a good idea as the project matures.

1 Like

@michael_henderson & @OwenWaller. You guys are hired :). Thanks for volunteering.

I’ll amend the top post to reflect these.

@michael_henderson, I think right now themes really needs some love. Many of the themes aren’t up to the latest code and we need to provide a good way for users to see the different themes. I’ve written a script that builds a theme showcase site but it depends on the themes each providing a couple images to work right. I’ll push it and let you drive it from there, if that’s ok.

@spf13 Ta :). But…

Yes, we do want the development branch. And yes, I do mean that master is frozen for development and should update from development when we are stable. So pull requests get merged into development first. My reason for wanting this is two fold.

  1. Anyone who downloads the source, but that via a “go get …” or a “git clone …” should be able to build a stable i.e. builds and passes all its tests out of the box. It should just work :). These are implicitly built on the master branch.
  2. We need a shared place for the maintainers to merge into. That should in theory be stable but might not be - hopefully if it is unstable that should only be for a short while, but that depends on life and other things :slight_smile:

If someone downloads the source, and wants to contribute they have two choices. Work on top of the stable master, or work on the more recent but unstable development branch. But, if we do it this way which branch they pick is their choice. At the minute, we are forcing them to use master, which might well unstable.

So it’s not so much about us as contributors - distributed dev. does give us isolation, it’s more about others. So think of new contributors of package maintainers who packaging up Hugo for Ubuntu/Redhat/Gentoo/Windows/MacOsX etc. Also think about source packages (which Redhat and Ubuntu/Debian all still use. Gentoo is source only). We want to give them a stable known state to make their life easier.

[Before you ask, yup, I always have a development branch for just this reason in all my other projects in and out of work. I then deploy form master only]

1 Like

Another vote for a dev branch. As I have been pushing updates to my PRs, oftentimes the build is failing for reasons unrelated to my code, which isn’t helpful for debugging.

+1 for dev

I apparently missed this thread.

I agree with a dev branch or something that would support a similar concept.

One thought I had, which probably won’t be feasible until later, is to try and get on a tick-tock release schedule, which has become increasingly common in various fields. Having major changes be either a tick or a tock and the next release being more focused on fixes, stabilisation, and laying the groundwork for more functional changes.

@spf13 I’m happy to help you and Hugo however you see fit.

I like the idea of tick tock, but I’m not sure if it fits for our development. I strongly feel that until 1.0 we should continue with the current pace.

What is your target for 1.0? Do you have a specific featureset / timeline in mind?

I need to give it more thought. The intent was to have 1.0 once the core set of features was complete.

Off the top of my head this would include:

  • pagination
  • better image/media support

I don’t think it’s too far off.

I also want to make sure the api is stable for 1.0. I know we have some changes to do there still.

I don’t think it’s very far off. Maybe another release or two before.

@spf13 @bep If there is a need for someone to manage documentation (granted, I only speak English), I’m happy to take this role. I’m an STM writer and publisher.