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.
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.
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.
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.
People want to be a part of successful open source projects.
Many people want to help but feel like it’s not their place to do so.
If you invite people to help they feel welcome.
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.
@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.
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.
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.
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
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]
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.
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.
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.
@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.
