Sustainable support plan

[addyosmani]

In order for us to continue scaling the project, I think we need to define a clear support plan moving forward that improves on the contribution guide. Especially now that we are more modular with more cleanly defined roles for our various pieces.

At present, I worry that our issue tracker is treated as a silo for issues with grunt tasks, generators, Bower packages, tech stacks and on. I feel we need to define what it is we actually provide support for on the master issue tracker and what we don't.

Not doing so will only increase the number of issues we receive once we add more features.

For example, if there are issues with a generator, those should be posted to the repo for that generator rather than on master. Issues related to Bower (unless definitely related to Yeoman) should be posted on that repo and so on.

@sindresorhus does this make sense to you or am I over-estimating how much of an issue this is? :)

[sindresorhus]

I completely agree. It is a problem. But mostly our fault, since we don't provide the needed guidance.

https://github.com/yeoman/yeoman/blob/master/contributing.md#issue-submission should clearly list what kind of issue that belongs where; generator system, specific generator, bower, grunt, specific grunt task.

[addyosmani]

Let's add as a docs task for #829. I don't mind taking it on.

[addyosmani]

Rough thoughts as I work out how to word this.

Yeoman provides an optimized scaffolding and workflow experience for creating compelling web applications. Developers use the new scaffolding tool yo and our generators which both are a part of the Yeoman workflow. Grunt is used for building their projects and Bower for package management. A typical workflow between this trinity of tools might look like:

yo webapp
yo angular
bower install angular-directives
grunt

Binary issues

For issues with the Yeoman binary, such as being unable to run Yeoman at all you should submit a bug ticket to the Yeoman issue tracker for further help.

Scaffold issues

Our scaffolds (such as angular above) are community-driven, with several of our default ones living under the Yeoman organization on GitHub. These are maintained by developers in the community around a particular framework. Issue trackers for some of our popular generators can be found below

• AngularJS
• Backbone
• Chrome Apps
• Ember

Build issues

As we recommend using Grunt for building your projects, the Grunt issue tracker should be used for support issues around building projects. Keep in mind however that if you have an issue with a specific task (e.g CoffeeScript compilation) it probably makes more sense to submit a bug report to the task in use.

Issue trackers for some of the common tasks used in the Yeoman workflow can be found below:

• coffee
• compass
• handlebars
• requirejs

Package management issues

If you have installed a package using Bower, updated a package or are experiencing issues managing packages, the Bower issue tracker should be used for submitting bug reports. If you are unsure where a particular problem lies, the Yeoman tracker may be used.

[addyosmani]

@paulirish @sindresorhus is the above going in the right direction? If so I can firm it up into a proper support guide.

[sindresorhus]

Developers use Yeoman together with Grunt

Not really true, they use the scaffolding tool yo and our generators which both are a part of the Yeoman workflow.

The webapp and angular generators are mutually exclusive.

it probably makes more sense to submit a bug report to grunt-contrib to address this as the official Grunt tracker should not be used for such issues.

Should probably be reworded to say something more along: it probably makes more sense to submit a bug report to the task in use.

The Yeoman workflow typically relies on Grunt for minification/concat of such dependencies, however we will let you know if an issue submitted is a Bower issue or a Yeoman issue.

Not needed.

Would be better to add a general note that the Yeoman tracker can be used if they aren't certain where the problem is, or something.

[addyosmani]

Thanks for the feedback! Well pointed out that it should refer more to yo as the scaffolding tool and consistently mention the rest as a workflow. I can also drop the last line as suggested.

+1 on the general note about support if unsure.

[addyosmani]

Moved to https://github.com/yeoman/yeoman/wiki/Support