What should we build?

[ProLoser]

https://plus.google.com/115485431256936261338/posts/C5DFPnHk9mk

A lot of us are becoming alarmed at the quality of posts, projects and resources popping up in the AngularJS community. The bottom line is the core team is too swamped to push 'Best Practices' or moderate anymore, and there is no officially documented best practices. It would be nice if there was a way to ensure / improve the quality of posts and projects that arise in the community through a centralized system.

Ideas that have been discussed:

• An official blog
• An official newsletter / internet magazine
• Pro reviewed-quality control
• A directory
• A voting and feedback system (StackOverflow-esque)
• A submission-for-review service
• Democratically run project (no 'you write for me' or 'i write for you' ownership)

Mix and match. We wouldn't want to discourage bloggers, and we know some of the best devs don't have the time to go to each blog and provide feedback (or blog themself).

CakePHP has the 'Bakery' service (although it lacks voting)

I personally have been actively working to provide a 'Best Practices' repository in the AngularJS wiki (instead of blogging) and the new book by @pkozlowski-opensource and @petebacondarwin is probably the closest thing we have now.

[jhanink]

@ProLoser Is there really a one-size fits all set of authoritative best-practices?

In Misko's Best Practices presentation, he starts off saying that the idea of best practices is helpful but that he'd rather offer various options for the purpose of considering the tradeoffs relative to one's needs instead of making global statements that something is always good or bad. He says only you can make the decision as to which is best for your case.

If the goal is to educate newcomers and serve as a discovery resource, then there may be new options cropping up all the time, such as core animation in 1.2. And if this is true, then this project is going to be an always changing target. Rather than settling into locked entries like Wikipedia, it should reflect "what is the best option for what conditions for what version". Perhaps some concepts are unchanging, but I suspect such ideas would not necessarily be angular specific.

I think the concern is that we want to see a good separation between the short list of "good resources" and "the rest". How that is controlled, presented, and maintained is important to the successful longevity of this project.

If curation is to have more than just a highly opinionated nature, wouldn't it be beneficial to assign a structure to all entries that describes what problem is being solved, what assumptions it makes, what tradeoff directions it takes, etc. That way, excellent guides and examples can remain excellent but still give way to newer ideas for more current approaches.

Just thinking out loud.

[ProLoser]

@zergworld actually that is exactly what I want to do with the directory. Since people are going to always be developing new techniques I want to have a central location that indexes them all and compares and contrasts them, both in quality and in nature.

[jhanink]

@ProLoser I think the need for good information goes beyond best practices. To help people find what they are looking for, what top level organization are you thinking of?

How about -

1. Supplementary reference documentation
   • elaborates on or explains material in the official docs that is either sparsely treated or hard to understand.
2. "pro guides" from the obvious recognized members of the community
   • e.g. @johnlindquist
3. modules
   • recommended libraries for various concerns
4. tools
   • IDEs, plugins
5. tips/tricks
   • smaller but no less valuable nuggets
6. anti-patterns / bad examples
   • with alternatives (edited per @johnlindquist comment)
7. info
   • the rest
   • blogs, projects, musings
   • maybe this is presented differently, e.g. just links or medium.com style

[johnlindquist]

I would invert the approach.

Gather bad examples and suggest alternatives.

IMHO, the AngularJS community isn't ready for an Ivory Tower/High Council until the community, as a whole, fully understands the paradigm shift to "declarative HTML". Then the "thought leaders" (or whatever you want to call them) will emerge because the community will recognize the quality of their work.

TL;DR Teach, don't preach.

On Fri, Sep 6, 2013 at 11:48 AM, zergworld notifications@github.com wrote:

I think the need for good information goes beyond best practices. To help people find what they are looking for, what top level organization are you thinking of?

How about -

1. Supplementary reference documentation
   • elaborates on or explains material in the official docs that is either sparsely treated or hard to understand.
     1. "pro guides" from the obvious recognized members of the community
   • e.g. @johnlindquist https://github.com/johnlindquist
     1. modules
   • recommended libraries for various concerns
     1. tools
   • IDEs, plugins
     1. tips/tricks
   • smaller but no less valuable nuggets
     1. info
   • the rest
   • blogs, projects, musings
   • maybe this is presented differently, e.g. just links or medium.comstyle

— Reply to this email directly or view it on GitHubhttps://github.com/angular-ui/community/issues/1#issuecomment-23957353 .

[AydinSakar]

@ProLoser can you point out the anti-patterns you see in Thinkster tutorials?

[AydinSakar]

@johnlindquist :+1:

[0xjjpa]

@johnlindquist I'm not sure that's the best approach... Not everyone is so open about critique and it might turn into just a shaming gallery.

My suggestion is a gallery of good projects, that are not To-Do lists, are complex enough to provide some learning, but not too complex to overwhelm the audience. I'm thinking about maybe something like (n)KB competitions (where n can be the number of your choice) with a good set of metrics that help us see how well done is the code. I would highly favor test coverage as a requirement, because that's also a skill I see lacking in the javascript world and could really help new developers.

[ghost]

@johnlindquist actually this is the perfect time for a technical Working Group to be formed. Hell one of their goals could be to produce a proper introduction to declarative HTML. The technical experts are already emerging.

for others in case they're unfamiliar with working groups:

Some people join, they list their qualifications and what the goals of the working group are. In this case it would be to produce a directory of best practices or projects/examples/tutorials/books that use best practices and to define what those best practices are.

Anything produced by the working group is of course only a recommendation that other people can choose to follow which is why it's important that members of the working group have the experience and education that other developers will pay attention to. For example, I'm a newbie to AngularJS and wouldn't be qualified to be part of a working group to define best practices. However, after a recommendation is put out by the working group, me and everyone else are free to criticize and demand revisions. This makes it open to the public and lets peer review happen.

[ProLoser]

@AydinSakar I actually spoke with @EricSimons and his team (and the mean.io team @linnovate) about the issues.

I have to agree with @omouse and @jjperezaguinaga responses. @johnlindquist I would think almost all of AngularUI and Egghead.io is what you stated?

[AydinSakar]

I would love to learn the issues about Thinkster tutorials and mean.io and hope you or them explain/discuss the problems you see.

[ProLoser]

@AydinSakar perhaps in another discussion. I don't want to derail this discussion.

[auser]

I'm a bit late to this discussion, thanks for the invite @ProLoser. Hopefully I'm not repeating or suggesting thoughts that have been said before as I've been heads down writing a book...

@johnlindquist I think looking at the bad examples side-by-side with the 'right' approach can be explicit and really effective in showing "why" things are bad vs. good.

@omouse I agree that a gallery of good sample projects is a good approach, but we could extract those out into lower-level implementation of the code and then people could check those repos for "good" sample application/implementation.

I think that we can get pretty far with providing a "get things done" set of resources 'cause afterall... that's mostly why people write code; to do things, right?

[revolunet]

Gathering bad practices, and explaning why its bad and how to achieve the same result with more reliable, testable, performant or maintenable code is another very educative approach which complements very well the various "best practices" articles and videos.

1) Pickup bad practice example 2) Explain why this is bad practice because of X, Y, Z 3) Propose alternative(s) and note the benefits

[auser]

We shouldn't call out where we find the bad practice, we should just show the bad practice, IMHO

Ari Lerner 520-360-9215 $ curl -iL http://ari.io

On Wednesday, September 11, 2013 at 12:36 AM, Julien Bouquillon wrote:

Gathering bad practices, and explaning why its bad and how to achieve the same result with more reliable, testable, performant or maintenable code is another very educative approach which complements very well the various "best practices" articles and videos. 1) Pickup bad practice example 2) Explain why this is bad practice because of X, Y, Z 3) Propose alternative(s) and note the benefits

— Reply to this email directly or view it on GitHub (https://github.com/angular-ui/community/issues/1#issuecomment-24218521).

[0x-r4bbit]

Pinging @cburgdorf on this thread.

[0x-r4bbit]

I think we should start to decide what we actually want when thinking about a kinda platform (or directory). Is it possible to list some facts we can rely on to get a bit more concrete about what we will do and build?

[ProLoser]

I'm going to throw @ericsimons under the bus here, lol. Our meeting was delayed until next week. I didn't want to get into what we had discussed yet before anything was confirmed.

If working with thinkster to pivot might fit the bill it would give us a good base to start with, otherwise we can outline and begin developing a new platform from scratch.

Eric: how critical is it for us to wait for Matt for just the initial discussion?