DocPad's community seems fragmented

[balupton]

I've realised this more and more since about May 2013.

We have people all working on different things, different implementations of the same stuff. Yesterday when chatting with @RobLoach we talked about how there are 3 browserify plugins, and even brainstormed a fourth that could be created by him.

Having 4 plugins created by 4 different people is not a good way to go about this I think, but rather having 1 plugin that is expertly designed and crafted by 4 people together, is a better way.

That plugin issue is one example, having discussions about rewriting DocPad in noflo, colojure, vanilla javascript, ecs, grunt, node tasks, whatever is the latest thing under the sun is another example. These are things where we know the way we want to go — modularize everything out, so individual components can be re-assembled differently — but for some reason, the discussions continue as if we rewriting all of docpad in it's monolithic core is still a thing, or that our implementation, not the problems we're trying to solve, is the most important thing — which isn't the case, DocPad is here today because of the problems it set out to solve, not the technology that it chose for how to solve those problems. Solving a user's problems is the most important factor, we could argue about rewriting DocPad until the day comes home, but without unification of the community, we won't ever get around to solving the user's problems.

Right now, this seems to be mainly due to the failure of GitHub Issues — #774 — seems to the largest factor here. We have a roadmap at http://docpad.org/docs/roadmap but I don't think it is referenced as much as the roadmap due to the amont of traffic GitHub Issues get.

In part, it could also because I've failed to some degree to be a unifying leader of the community, in the same way that Shuttleworth is able to unify not just Canonical but the Ubuntu community as well in tremendous ways, we need the same level of unification and leadership in the DocPad community as well.

Suggestions and discussion welcome.

[greduan]

I still believe we need a forum system. Maybe something like Discourse but I think a formal "forum" should be used.

To have this kind of discussions that is. GitHub issues would of course still be used but only for dev tasks, todos, bug reports etc. And they would only become a real bug report on the GitHub issues once it passes through the forums and it is agreed that it is one, otherwise the GitHub issues would continue being somewhat chaotic.

The IRC can continue, but it is rarely used AFAIK. It is used for conversations but these conversations could be had in the forums as well, a little more lag but they're not conversations that require chat. IMO.

That's just my two cents, move all discussions and stuff like that to a forum system.

[RobLoach]

Having 4 plugins created by 4 different people is not a good way to go about this I think, but rather having 1 plugin that is expertly designed and crafted by 4 people together, is a better way.

Although this can seem like a detriment, I see it as a benefit to the way open-source works. If one solution doesn't work for one person, they have two options:

1. Improve the solution to better suite their needs.
2. Build a new one that's to their own standards.

The DocPad GitHub organization could promote some of the third-party plugins out there by forking plugins into the /docpad namespace. This would give users a clearer idea of what's out there and not have to re-invent the wheel, while allowing the DocPad GitHub organization maintainers the ability to keep the plugins up to date.

I still believe we need a forum system. Maybe something like Discourse but I think a formal "forum" should be used.

I'm unsure of that, as it would just end up being another un-maintained place to have discussions. At least people look at the issue queue on and off. If we organize the labels a bit better, the GitHub issue queue might remain a pretty good place to have support discussions. We really have to look at the problem that we're trying to solve, before introducing a new system which might still have the same problem 😉 .

The IRC can continue, but it is rarely used AFAIK. It is used for conversations but these conversations could be had in the forums as well, a little more lag but they're not conversations that require chat. IMO.

I'm on there all the time, and have a daemon that logs my away chat for me. Would love to see this leveraged more. I see you on there, and stongo, a few others regularly. I much rather the quick nature of the IRC vs a full blown forum. It's better to read discussion conclusions in an article rather than back and forth discussions in a forum.

[greduan]

and have a daemon that logs my away chat for me

Check out this URL which logs stuff already: https://botbot.me/freenode/docpad/ :)

I can see your point about the IRC. The thing is not a lot of people visit it constantly, and IRC is a place for live conversations, which doesn't work with all the timezone differences. See my point?

[Naatan]

For what it's worth, I'm developing a "resource section" for komodoide.com using DocPad. The way it works is it basically is using github as the main repository and people submit their "resources" to one main "resource repository" which basically keeps track of all the resources that have been submitted. This data is then used in a DocPad plugin which pulls all of the submitted github repositories from github and allows me to render their information using DocPad.

It's still in very early development but something like this might also be useful in DocPad as a means of centralizing all submitted docpad plugins in one location on the official docpad website and encourage users to participate (the current plugin list on the website is a bit underwhelming).

I've pushed the current version of the plugin here if you're curious - https://github.com/Komodo/komodo-website/tree/resources/plugins/resources. This code is not stable, mind you. In fact it's probably best regarded as a prototype.

[greduan]

@Naatan :o Komodo. I remember when I checked that out years ago, looks so much better now. lol

Thanks for this. I dunno if we'll go with it but it certainly is something to discuss. :)

[Naatan]

Yeah it might not be a perfect fit for DocPad's needs, but the basis of my suggestion is still relevant - to have a central place to share and show off your plugins. It's not just about people sharing the plugins they made but about them "wanting" to share it.

[greduan]

Right. :)

[balupton]

@Naatan is bevry-archive/helper#1 and https://github.com/docpad/website/search?q=dynamic&type=Issues related to your suggestions?

[Naatan]

Somewhat, although what I am doing and would suggest is using the github data (if available) of each repository that the plugin is hosted on to flesh out the pages on whatever website will be displaying this data. Eg. show the readme, show releases, show forks, watchers, etc.

My current implementation does all this bug still needs some polish. The point is though that simply showing a name and a description is not going to be very enticing for (potential) plugin developers. I know that sounds superficial but it's also true.

[Naatan]

For what it's worth, here's the docpad plugin "in action" (currently on a test environment): http://qa.komodoide.com/resources/

I'd imagine something similar could work for Docpad plugin repository.

[mikeumus]

Looks cool @Naatan. Thanks for sharing this option. 👍

[balupton]

Closing due to age.