search

less / less-meta

Like meta.stackexchange, but for Less. For documentation, please go to less/less-docs
MIT License
5 stars 1 forks source link

Is Lesscss.org getting a blog? #2

Open matthew-dean opened 10 years ago

matthew-dean commented 10 years ago

I saw on less-docs that there was a place for a blog, which I think is a great idea. Further, I think it could be something that is community-contributed to (and community-administered), but it would need some planning (as any content needs content strategy).

Anyway, just wondered if the blog had any prior discussion around it, or plans in the making other than "we should have a blog".

Synchro commented 10 years ago

I see a lot of projects doing blogs on github pages with jekyll. It can be a nice way to work as blog posts can be contributed by PR. I've played with Jekyll, but found it does take a fair amount of work to set up. There are some starter projects like jekyll-starter.

I think a better name than less-meta would be 'more'...

matthew-dean commented 10 years ago

"More", despite being dreadfully punny, is already Alexis's name for a ruby port of Less (although it hasn't been contributed to in 2 years).

jonschlinkert commented 10 years ago

I put the placeholder for a blog until we had this discussion.

I think it could be something that is community-contributed to

exactly what I was thinking. agreed.

github pages with jekyll.

Yeah, I created Assemble (http://assemble.io/) for this purpose, which is what we're already using to build the docs. Assemble works like Jekyll, but it's JavaScript and runs on node.js. It's also much more powerful and flexible than Jekyll, and IMHO easier to learn and use. here are some resources for assemble: https://twitter.com/addyosmani/status/413103021581557760, and a blog post that does a pretty good job of explaining it https://twitter.com/ddprrt/status/402430753494929408.

I think a better name than less-meta would be 'more'...

I mentioned this on the readme, but this is what inspired the name: http://meta.stackoverflow.com/. I wasn't trying to be clever, it just seemed to fit

jonschlinkert commented 10 years ago

also, regarding guest posts I suggest we have two hard-set rules:

  1. create an issue first to discuss with core team, don't just do a PR
  2. digitally sign a basic form agreeing that none of the content is plagiarized, and that they use proper references for sources
matthew-dean commented 10 years ago

Well... blogging via using build systems seems kinda crazy. At minimum, it would be a barrier to contribution. I wouldn't assume that contributors we might invite who could be qualified to make some good contributions to Less would necessarily be programmers or know anything about Github. I was thinking something more like a basic Wordpress contribution page kind of thing. Or maybe at least a front-facing form that was friendly. But you'd want a searchable database system, so I'm not sure about Jekyl / Github / JavaScript, etc... Unless github pages allows you to build a more friendly front-end? Not sure.

jonschlinkert commented 10 years ago

At minimum, it would be a barrier to contribution

I have to disagree, it's not possible to be easier than markdown. If you can a) write markdown, and b) figure out how to do a PR, then you're good to go. No need to build it first. But even if you wanted to all you have to do is npm install, add your markdown file to the ./content/posts/ directory, then run grunt and it's done.

I was thinking something more like a basic Wordpress contribution page kind of thing.

WordPress is way old school Matthew, and it's way, way more difficult than submitting a page in markdown. Just as a blogger has no need to know how to write PHP to make a post on wordpress, there is no need to learn the inner workings of Assemble either. I have a lot of sites running with wordpress, it was my system of choice for years. At this point there is no way you can convince me that any system is easier than writing a post in markdown.

If we went with wordpress:

But you'd want a searchable database system,

Searchable yes, but "database system", why? We can use https://github.com/assemble/assemble-contrib-lunr, or @doowb or I can create another plugin that does what we need.

I built Assemble for designers, which has worked out based on the issues we get, comments on Twitter and blog posts that have been written about it. It's now the fastest growing site generator on GitHub, the most popular JavaScript site generator, the 3rd most popular Grunt plugin, and it has been downloaded ~200k times in the past 7 mos.

matthew-dean commented 10 years ago

Well......

At this point there is no way you can convince me that any system is easier than writing a post in markdown.

That's great but...

  1. I can't write markdown. I always have to look stuff up. However, pressing a "B" (or ctrl/cmd-B) when I want to bold something is about the easiest you could get, which is all Wordpress requires. I actually hate markdown and feel like it's unnecessarily cryptic, especially when software has solved formatting interfaces for 20+ years. But I'm not going to go into a debate about how lazy markdown is from a user interface perspective. I understand it works well for many people. I am not one of those people. (I also hate command lines. And I'm not fond of zombie movies / shows.)
  2. You don't need to know PHP to set up Wordpress. Certainly not to submit a post. But I'm not really trying to make the case for Wordpress specifically. As long as someone who writes a blog post doesn't HAVE to use markdown (but can), or doesn't have to run a build process or something like that, then I think it's fine. I'm just saying it would be good to reduce barriers. Markdown might be one for someone like me, or someone who's more a designer / developer than developer / designer. Another might be navigating Github. I know lots of web devs who are experts at Less, and wouldn't know the first thing about Github. For one, even if they use source control, they may not have used Git.

So, I'm saying let's not presume that what works well for us is what would be most accessible for everyone. Unless we're basically saying that the only part of the Less community we want to contribute to the blog are active Github users. My feeling is that that's actually a small subset.

So, if Assemble can do lots of cool shit, that's great. What you've built sounds awesome. But I can't be the only person who would be annoyed at the thought of contributing to a blog via forking into a repo and pull requesting. The idea of that makes me want to punch my own face and then watch a season of The Walking Dead. Please God No.

Synchro commented 10 years ago

Assemble looks cool, but don't you have to use an external build system since only Jekyll is supported by gh-pages? Doesn't that mean that if you have a rebuild-on-commit hook, it has almost as much in the way of requirements as hosting wordpress?

I often find that forums that allow code snippet posting with wysiwyg editors don't work properly. I've used codemirror in a few places and find it does some very unexpected things - for example in CSS mode it doesn't allow body as a selector!

Markdown has been growing on me, to the point where it's annoying when I find it's not supported (possibly due to the failure of wysiwyg editors), but my favourite markup syntax to date is the one used in Trac. I particularly dislike Markdown's syntax for links, it's very clumsy.

doowb commented 10 years ago

If it were me creating a blog for my project, I would use what I'm comfortable with (disclaimer: I also work on assemble). If I'm going to invite others to be guess bloggers and they aren't comfortable with the github way of PRs and markdown, then let them write a post in whatever they want and convert it to markdown for them. This will give them the freedom to cross post on other sites as well.

Also, there are a few tools that can assist with writing markdown.

- Just my 2 cents.

PS: I think it's a great idea to allow people to guess post on your project's blog.

matthew-dean commented 10 years ago

Markdown I don't consider the biggest barrier. I recognize that's more a personal preference, and may not be that big a deal for potential contributors. And if it produces more strictly formatted results in an easier way to set up, that's alright. I think needing to do pull requests for submitting a text block is what seems unnecessarily complex, since it requires the author to have a lot of things in place and a lot of supplemental prior knowledge just to submit an article about Less.

I'm happy to help moderate, and if that means cleaning up a little formatting, that's fine.

SomMeri commented 10 years ago

I think that pull requests are bigger barrier then markdown. Anybody able to learn css and less should be able to learn markdown/html/whatever syntax for list and code snippet in no time. No syntax is universally loved anyway.

If there would be link to good online markdown editor, they should be able to write article and open new issue with it once it is done. I do not think we will have hundreds of contributors, so it should be manageable. Pull requests have to be merged too.

I use blogspot for my blog and it was super easy to start. It has one big text area with toolbar on top which makes it easy to learn syntax. It also has big "save", "preview" and "publish" buttons so you immediately know what you do, no reading necessary.

It is possible to clone repo, modify/create new .md file and send pull request directly from browser if you use github flavored markdown. However, it is not comfortable even if you overcome the initial confusion. You have to be careful about things outside contributor should not have to care about (proper directory, file name ending with .md).

jonschlinkert commented 10 years ago

Guys,

image

Then you click "commit" to do the PR.

seven-phases-max commented 10 years ago

There're also things like Prose and StackEdit with GitHub integration for "pleasant" md editing. But to be honest I wonder if "md editing" > "doing PR" > "writing a good blog post" :) So far I'm not aware of any except those written by @SomMeri and @lukeapage... Most of others are just:

Look Ma Variables!

and then goes a copy-pasted example from the docs :)

jonschlinkert commented 10 years ago

should not have to care about (proper directory, file name ending with .md)

Okay, for argument's sake, Assemble doesn't care about file extension. We can make that discrimination in the Grunt file. The directory is content/posts. In any case, here is our theoretical guide for posting, which would be right near the top of the readme on the repo:

"Do you want to write a guest post for the Less blog? Follow these instructions:"

  1. Write the post in markdown, and name the file with a .md extension
  2. Go to the ./content/posts directory and click on the plus sign, as in the following image: image

That is the instructions for posting here. @matthew-dean or @SomMeri please write the equivalent guides for posting on WordPress or Blogspot so that we can compare and contrast. This is not rhetorical. For us to consider moving to a different system, we need to have a sense for the entire workflow would be, both for the core less team, and for guest bloggers. This includes answering the questions I asked above:

With all of that said, why are we trying to eliminate ALL barriers to making a post? There has to be some consideration for a) who will most likely be posting most of the time (IMO, the maintainers), and 2) ease of maintenance for the maintainers. The questions I listed are just a start, I'm sure there will be more questions. I currently have 75+ wordpress sites running, so I'm fully aware of how blogging systems work. IMO, using Assemble with GitHub is by far the easiest possible solution for maintainers, but it should be relatively easy for guest bloggers as well.

We're going from zero to "something", we just need to keep this simple. Any external blogging system is going to complicate this in ways that aren't being addressed.

SomMeri commented 10 years ago

@jonschlinkert I'm not suggesting blogspot, it is not suitable for this. It is usable only for single person blogs. I only compared how much you need to know to start.

I think that if someone takes the trouble of writing good non trivial blog post, which takes a lot of time (at least to me), I'm willing to do whole fork-send-pull-delete-now-useless-repo dance for him. There is not going to be that many new outside contributors, so I can do that twice a year.

Then they can just open new issue and past content there or link gist. I do not think it would be that much more work then merging pull requests. Reading what they wrote will take more time anyway.

matthew-dean commented 10 years ago

When designing a product, I start with what I want to achieve, not the technology I'm going to use. Which is why I said I wasn't advocating for Wordpress specifically. Deciding the technology would come later. First is: what is the product? How would someone submit? The hardest part about maintaining a blog is not the underlying system; it's getting contributions. The rest of the problems you list may be problems, but they're not the hardest problem IMO.

So, instead of listing out steps for a platform, I would ask instead: what are the ideal steps? What's the least friction? Yes, the least friction for maintainers / admins is important, but as @SomMeri pointed out, it's not the hardest friction point to solve, nor does it take the most time to solve it.

The least friction for contributors?

  1. No special accounts / logins required.
  2. No special Github knowledge needed (or any Git competence at all).

That's a scenario like:

  1. Go to lesscss.org/submit.
  2. Fill out a form with your article (with a rich-text box or upload).
  3. Press submit.

The underlying platform can be a lot of things. Admins could even take posts and add them via Github pages or whatever. Sure, Wordpress has plugins that allows forms like that to automatically create posts, and there are other plugins to review / approve posts, but if it creates too many add-on problems, it may not be the best solution. It would be hard to say at this point.

The hardest problems are:

  1. How are you going to get submissions?
  2. Who will review / edit / solicit submissions?
  3. What is the post calendar for the blog? (How will the blog be kept relevant)?

If there isn't a content strategy first for a blog, there might as well not be a blog. Once we know WHAT we want to achieve with the blog, who will administer it, and how we want to handle submissions, we could decide, as you said, the best way to do that based on what's comfortable for the administrators.

matthew-dean commented 10 years ago

Jon, this is a discussion thread on what the blog is. I'm asking you.

To quote you:

"I put the placeholder for a blog until we had this discussion."

The discussion started with the blog, but veered off into technology, which is off-topic. That's partly on me for also going off the rails. But again, the discussion topic: what is the blog? I'm not aware of how one would make commits for a project which is not defined. I mean, I could, but what would they be? If there are the beginnings of a blog strategy, please share them. That is what I'm asking: what is this blog and how can we help make it successful?

You may know what you're doing and how you think people should be contributing, but we are not in your head. Do you want to have the discussion or is discussing it making things difficult?

jonschlinkert commented 10 years ago

Sorry, that was harsh. My apologies, which is why I deleted that comment. I think we should focus on getting writers and topics at this point, not technology. Give me a minute to post a more thoughtful response.

jonschlinkert commented 10 years ago

The discussion started with the blog, but veered off into technology, which is off-topic.

yeah, so just to clarify my initial reaction, I read "Is Less.js getting a blog?" as "will we have posts to publish, and/or will we have people who actually write something for us to post?". In which case my answer is, "I'm not sure. I think others need to help drive that part, so I have the blog section disabled for now."

But it seems this conversation has focused on, "do we have technology for a blog already in place?" In which case the answer is "yes"... and I wish I could add "but, if something else is clearly better, we should do it now before this goes live", but my gut and experience tells me that at this point we're going to suffer more paralysis from analysis, and the project just won't happen.

We're pretty much in agreement on this:

The hardest problems are:

How are you going to get submissions? Who will review / edit / solicit submissions? What is the post calendar for the blog? (How will the blog be kept relevant)?

IMO, the hardest part will be actually getting it done, and then having competent maintainers (no different than any project). So we need to just get it done first, after that comes "making it great", which will include finding great people to write great posts, etc. But IMO, that is a completely different topic that belongs on a different issue. I'd enjoy discussing strategies for this if someone wants to kick it off.

If there isn't a content strategy first for a blog, there might as well not be a blog.

I don't agree with this point, and I think it might be part of the cause of the over-analysis here. By nature, blogs denote informality. Blog posts aren't "articles". Instead, they are meant to be "real" and authentic, not sanitized and crystallized. So my bet is that most of our posts will end up being a) primarily from the Less.js core team, and b) about Less.js "happenings", roadmap, etc.

So my recommendation is that we shift focus to getting writers, and let them propose interesting topics.

matthew-dean commented 10 years ago

Programmers? Over-analytical? Well, I never! ;-)

I agree that initially, to get the ball rolling, it will probably be people already attached to Less.js. Luke's already written some good blog posts elsewhere on Less. I was planning to put a blog about Less on one of my Less-related websites. It makes sense that we'd talk about what we know, since it's front-of-mind often. We could even make LessCSS.org more of a HuffPo of Less articles (aggregation / re-posting with some unique content).

Most of what I was planning to write about is basically new patterns that emerge from using Less that just don't exist in CSS.

For example, one of my favorite patterns of Less abstraction is stuff like:

.my-class {
  foo: bar;
  &, &:hover {  // <-- this
    background: gray;  // apply something to both the element and its pseudo-class
  }
}

I'm sure people have more. For example, the first time I saw a fellow dev do this, I realized I'd never thought about using Less this way to reduce output (but keep things organized):

.overview {
  &-title { }
  &-author { }
}

I'm sure there are more, and that's something I'd love to see.

So, yes, you're right, long term, we'll probably need to figure out what to do next, but if we had a number of possible articles / topics / authors lined up for the first months of a blog, we could have some runway to figure out how to bring in external contributions. Maybe we could first ask all the primary admins to sign-on for a post or two? Then, asking other active people on Github. And by then, maybe we'll have a streamlined submission process?