This post should primarily collect all the voices out of the community to shape this idea more and more. Remember, that this only a concept we create at the moment, since some other corners of Hugo should get improved first.
The blog should look similar to the news section of Jekyll. This are the current ideas for posts:
previews of upcoming cool features. Tech-savvy users and theme creators would be informed even if they donāt hang out on Github to follow the current developement of Hugo.
Do you like this idea? Or do you even have some other ideas that should be discussed? Feel free to jump straight into the discussion.
I really like the idea of a blog. Are there enough community members
that would be willing to post to it to keep it active and engaging?
Iāve been through this before with another open source project. A blog could have some big pluses, but also minuses if not done right.
I agree and disagree with @bep. As much as the core development of Hugo and the people behind it are the priority, I donāt think one thing needs to wait for the other.
The key thing is that a blog should have an objective. This is where it would help Hugo. Thatās not to say it has to be a work of art, but if the last post was the May 25 release notice for 0.14 then it is probably better not being there at all.
With that in mind, a blog could be part of a plan / aproach to market Hugo, and I mean that in the open source sense. So not āselling itā, not pushing it on people, but making it look better for people who wonāt otherwise get to know how good it is.
So my advice / idea is that this becomes a job for a martketing team (alongside the documentation and testing teams). The people in this team would have the responsibility of ensuring the regular postings and quality (for example, minimum 1 per month to show project is active). So if no-one else contributes, between them they create the posts, and ecourage contributions.
Other things covered by this team could be:
something @bep mentioned, highlighting / giving more credit to contributors (such as a contributer listing page). Again the marketing aspect of this is it makes the project look more open and encourages mmore users to become contributors.
looking at ways to make it an easier entry for newcomers (tutorials, working with docs team)
future ideas to put out there for consideration / inspiration
making contact with developers who have built Hugo sites and / or work with Go, to get interviews with them for the blog, with (hopefully) some inspriation, ideas, hints and tips
Thanks @mikeaja for highlight this points. Marketing Hugo beyond the borders of Go would increase the number of users and members in the community. At the bottom line: Hugo will grow.
Iād rather do release posts there and upcoming previews of cool features would be great to be on the blog as well.
It would broaden this scope since it could give us all the advantages listed above by marketing Hugo and changes in the project. And more:
writing about upcoming features could give us also feedback during the developement. This could lead to more participants in the project and contributions, because could find easier access to the developement.
showing best practices / tricks and tricks communicate the flexebility and power of Hugo
I could even imagine to except selected guest posts. What popās up in my mind are tutorials of how to use the hugo caddy plugin (written by @hacdias), how to implement a search with bleve / HugoIdx or to share the experience of companies that use Hugo.
We could extend this list even more, but this should be enough content ideas to fill a schedule with regular posts. As @mikeaja mentioned, a blog could also have the opposite effect if it isnāt maintained.
Beside the content we also should talk about the technical part. I can understand that more complexity means more work, as @bep stated. But setting up a blog should be that difficult, since this should be the ādaily businessā for Hugo.
We could build the blog in two ways.
If we add new site to the docs, we wouldnāt need to add automatization because itās already there.
Otherwise we could decide, to outsource the blog into a seperate subdomain with itās own repository. In this case @spf13 would need to add the automation when he finds the time to do it.
Either way, I could to setup the codebase this project. But this are just my cents for now. Letās see what the others say.
My advice is first decide what the marketing direction should be, if a marketing team is the way you want to go.
What I mean is, weāve talked a lot about the blog and I think it seems we all agree how that could work (and what pitfalls to avoid). But marketing as a whole in the digitial space is something quite diifferent and has infinite options. This means to be effective needs to follow an approach where what is being marketed and āsaidā about Hugo is the same as the objective(s) from the developers / @spf13 's perspective.
In other words, marketing will work when the way it is put out there and desccribed matches what it is and wants to become.
Again we can look at Drupal to see how this didnāt work. Most of the time Drupal was described and recommend by developers who knew it well. So they would talk about it in a way that was not the same as the experience for new users. This gave it a lot of bad press. Only later did they realise they needed more marketing focused on connecting the dots (which is probably one reason why Joomla is more popular).
Another example is Metalsmith. So many comments about it refer to one set of tutorials (by a user) which probably did more for Metalsmith than itās own docs. This was pure luck that the user was experienced Metalsmith and very good at writing tutorials. Without that tutorial (one of the first things you find on Google) I think that system would be less popular.
So both those systems could have benfitted from a marketing (in the open source sense) plan, that connected those dots earlier. This is not an easy thing to do, so it needs knowledge of this field and quite a lot of discussion.
@spf13 Iāll create a repo to setup the basic code frame for the blog. Later Iāll transfer of the ownership of the repo to you.
@mikeaja Wise thoughts. We need to evaluate our current documentation in terms of accessibility for new users. But this shouldnāt stop me to create the code, because this code seems to be more related to the actual content we provide.
Not suggesting stopping doing stuff. I was more thinking of @spf13 and the project as a whole. A marketing focus, in addition to the other areas, gives a new and other face to Hugo, one that may be the first thing some new users see (depending how they come into the project). With this in mind how this is all worked out annd set up is quite important.
Drupal seem to think the solution to growing the project was to throw a load of support and āhookā access to the core code to developers. The result was loads of very cool modules and improvements, many unfinished or neglected modules and a very steep learning curve for new users, many of whom ended up going to Joomla or Wordpress. Ok, thatās a bit of a critical view as Iāve worked with Drupal, but a lot of truth in it.
The key thing is that, it seems in the beginning no-one within Drupal circles said āhold on, what about the impression we are giving?ā The Wordpress and Joomla people did. Iām think thereās lessons to be learned that show the importance of first and second impressions, thatās what Iām pushing.
My point was more about what impression we could end up giving if not considered enough (not necessarily bad, just not the same as @spf13, you and other key members might have.
Still, to answer your question, I think Hugo comeās across as having great potential but only fully accessible to those āin the knowā. Itās this latter part Iād like to change.
I like the idea of a Hugo blog that accepts pull requests for guest posts like Gopher Academy. There are tips & tricks for using Hugo that could be cross-posted there.
As a reader, Iād be very interested in more How To type material with Hugo in mind. For most of my Hugo work, I use Howtoās written for other generators and then translate them for syntax differences.
I also like the idea of a blog, but I think we should watch out to make it look like a developer blog. In my view, a Hugo blog is a good place to contain news and information to keep up to date with Hugo for non-developers. Thatās because I figure that people familiar with pull requests can also find the open issues in Github and the āGithub pulseā to see what has happened recently.
As already mentioned in this thread, a blog can be a good marketing tool. But should a blog market to developers or help to make Hugo more widespread among non-developers?
Personally, for a Hugo blog Iām more thinking about something like WPTavern with updates on new releases, themes, and āpluginsā as well as things happening in the broader Hugo environment (like an interview with someone from the community, a top 10 of advantages of a static website, perhaps some general website development tips & tricks, tips for writing blog posts, statistics about the Hugo growth, etc.).
That approach is also like the Ghost blog, which clearly caters to non-developers and people (relatively) new to blogging, while the Github repository and developer blog are for the technical details aimed at developers.
Iām somewhat concerned that if we āgo all technicalā with a blog (and use things like pull requests for simple guest posting), it will be off putting to non-developers that are new to Hugo.
But, as @mikeaja already said, it all depends on which direction Hugo should go: stay within the developer circle or go mainstream?
From what I understand, it is not wanted that Hugo should be / stay in the developer circle (in the sense of being technically challenging to use).
However, given the tool that it is, it wonāt / canāt be mainstream like WP, because it doesn;t have the accesibility of wordpress.org and a non-developer focused backend. In my opinion, tools like Hugo wouldnāt / shouldnāt work like that anyway.
But that doesnāt mean we all canāt help to simpify the learning curve, especially given the Go factor (for example, I imagine many come here with a PHP background). A blog can help bring folks in, create interest, but itās the documentation that does the rest.
Why shouldnāt work Hugo that way, you think? Thereās not much wrong with accessibility and more non-developer features, I think.
When I choose between Jekyll and Hugo, the greater accessibility and lower learning curve of Hugo (e.g., the single file to run instead of multiple dependencies to install) was the most important point. Even though I could have learned Jekyll, why bother? Hugo also creates static website and is more accessible (to me). I think that even developers value accessibility, since (free) time is precious after all.
So I do think that Hugo should go to the path of more accessibility and (optional) non-developer features.
I didnāt mean it couldnāt be more accessible or clearer, just that the mainstream / non-tech user side of WP is in a different space to Hugo (or Jekyll). For example, friends have created blogs with wordpress.com eith no idea of the tech side. Static site generators will never fill this space. Similar to what @spf13 said in anothher thread, a potential Hugo use should have at least HTML, CSS, some kind of deployment knowledge, and Iād say a clear understanding of static vs dynamic. So Iād see that level of knowledge as the starting point where blog posts are concerned.
I think a good compromis would be to seperate both āmainstreamā and more technical developer posts in the blog. This way, both worlds would benefit from it. I would split up the content the following way:
developers:
Discussion about upcoming features used as feedback during the implementation
Changes in the core of Hugo (renaming variables etc.)
Mainstream users:
Release notes
cross-posts in collaboration with others
something similar to WPTavern that highlights tips and tricks, best practices or shows new theme releases
the Ghost blog seems to be more about marketing yourself: how to increase the number of readers, how to write good content, how to find inspiration for new topicsā¦
One thing to add, that is often true of blogs is that what they are good at depends who is available / capable of writing it.
For example, some companies have good news blogs that visitors return to, others donāt due to uninteresting news, writing or no updates. Same is true for how tos, technical discussions, articles and interviews.
I suggested setting up a marketing team emcompassing a blog, not defining a marketing vision here and now, or a blog vision (unless @spf13 already had it), This is because we donāt know who can write, contribute and create this stuff (in an interesting way).
With open source community projects, I think this is also true of teams. I suggest before assigning anything, some content needs to be there and then everyone can see who can do what with it.
In other words, I do appreciate intially someone has to step up to start it off, but I advise being careful of creating a funnel where a few good people do a lot of work, which then closes the space (unintentionally) to wider involvement and input.
I think a good idea is to get the creation process going from as many people as possible, maybe a test blog space initially where anyone can contribute a blog and everyone can vote which are interesting for a blog and good for Hugo. For example, it may well be that the best writer is none of us, the person with the best ideas for content maybe none of us, or it may be one or more of us.
I hope this makes sense. Iām not saying anyone is doing anything wrong, just that Iāve seen this before and think I know the pitfalls.
That sounds like overcomplicating things to me. The blog doesnāt need to be the next great novel in terms of ābest writerā or ābest ideasā. Also, do people have an objective standard for ābest contentā? What might be nice writing for you might be awful for me, and what I think are good content ideas might be way to basic for you.
I donāt think an āopen source approachā works with a blog that (presumably) needs to be periodically updated. I think it would be more efficient if we have 2-3 editors that create content and/or overlook guest posts. Those people will then also have the accountability to keep the blog updated.
The drawback of including as many people as possible in the creation process is that no one really feels responsible for creating a nice blog nor feels ownership of the blog. Perhaps that might work when the blog is already up and running, and people are willing to join the effort by sending in blog posts. But getting it off the ground likely needs another approach.
In analogy to Hugo, would Hugo have grown past its initial commit if Steve didnāt feel ownership of his project? Or, more recently, if Bep didnāt feel responsible for helping people on the forums? In my view: of course not, because whether we like it or not: all projects (whether it being a blog or Hugo itself) depend on a few good people doing a lot of work.
Good points, and I agree in general (not that Iām the one deciding anything here). Sometimes my forum posts become only a cursory version of what I want to say. Maybe over-complicating, but it was just for an alternative point of view. I have seen an OS project suffer from this funnel I mentioned.
Your analogy is great. My question is does it support one view or the other?
Steve @spf13 and Bep @bep (feel I should tag while talking about them) are those kind of people that make the open source world work, not just because of what is created and the obvious skills but the whole open and inclusive approach.
In my opinion, people with the same skills but different approach would not have had the same success, and would not have encouraged the important contributors to join in. So I think itās just about being careful not to limit that openess by trying to progress.