[Discussion] Rethinking JsTips goal

[loverajoel]

One month and a half were born Js Tips with the concept of "One tip per day", 46 tips after these are my thoughts...

One tip day was an ambitious goal, even more, when the objective was a good quality and a useful tip.

We had really good tips for these days, excellent tips, but for the received feedback (and you can see that in the issues) show me that by follow the goal of one tip per day, I merged tips that maybe required more review.

This kind of things make me rethink that if we want to keep JsTips like "the source of the truth" we have to review the concept of "one tip per day, maybe we can merge one tip per day, but maybe another days not, because maybe there aren't a really good tip ready to merge.

Seriously, this is not about the pass tips and the people that sent his tips, I'm pretty sure that without his tips this project should be dead, this is only about improve and make more useful the project.

What do you think about this?

Thanks

Joel

[gcjbr]

I think that's a natural evolution of the idea. Inevitably one day no good idea will come up and, in that case, it would be better to leave it be instead of filling it with a not so good tip or something too obvious.

Sure, we all would love one amazing new tip each day, but that won't be always possible. In that case, I think quality should be considered over frequency.

[kurtextrem]

What about that one:

• For now we switch to "one tip a week". This leaves us empty room for reviewing tips and discussing (click "Watch", get notified about PRs and issues, join the discussion!)
• If (too) many new tips are coming in, we can switch back to daily (as the previous measure gives us enough time to review the new ones, so we publish the older ones first)

[Pixeluh]

@kurtextrem I agree with your first point. If we're handing out one a week, we'll have quite a bit of time to revamp the quality of individual tips.

Quality should always be before quantity.

[radibit]

Totally agree with the stated opinions by @souljacker and @kurtextrem. Definitely it's really hard to keep high quality on the reviews for all purposed tips on a daily basis.

I believe it's a good idea to switch to a different time frame, though I'm not sure if this should be once per week. Maybe at least twice per week or on a scheduled basis excluding the weekends like every Monday, Wednesday and Friday.

Of course this is something which depends on the amount of the tips and can vary in the time.

I'm also more than happy to help in the review process or in any other possible way as I think JSTips is really a great initiative!

[adaniloff]

Why do one need to bind a frequency to this publication of a tip?

I think it should be like "one tip after another" more than "one tip a day/week/month/whatever".

If two tips are good enough to be published the same day, that's great! But if they are not ready to be released, better waiting for more quality than publish some wrong / unclear tips.

I think too, maybe categorizing tips (by difficulty, library, etc) could be nice. Sometimes I wanted to check some old tips, and I struggled a bit... But it's only one month since the beginning of this project!

Sorry for bad English, I really enjoy this project tho ;).

[loverajoel]

+1 to @adaniloff, I think that is better don't set a frequency

[zenopopovici]

I think a way forward it to set a bunch of rules:

1. Tips should enter an "under review" phase where everyone contributing can vote on a tip (OK/NAK) in an Issue or PR.
2. If you want to "localize" tips, you will get a lot of requests that are basically just translating text. I don't see why tips should be translated. It's not a software for users where you need that kind of localization. You'll reduce a lot of overhead work with this, work that should be pushed to the improvement of existing tips and review on new tips.
3. Set basic code guidelines so that all tips use the same formatting, language, variable names, structure, etc.
4. Tips should not be bound to a time constraint. This only decreases the quality of the tips and also puts unnecessary stress on the maintainers to deliver. Once a week is great for a start, and then you publish whatever number of tips make it trough review.
5. Once this gets bigger you might want to publish them, also users need to know that they can freely use them, so every tip should be bound to a simple free-for-reuse license.

There may be other stuff that I'm not aware of. ;)

[loverajoel]

@jucrouzet

1. :+1:
2. Translated tips are merged without code review because it's only a translation
3. :+1:
4. :+1:
5. I don't understand what are you trying to say, now jstips is open and free for reuse

[adaniloff]

I kinda agree with the comment above by @zenopopovici. Especially the 1., 3. and 4 :)

EDIT : @loverajoel ahah that's fun, same reaction :) EDIT2 : for the 3., I personnaly like those rules!

[zenopopovici]

@loverajoel

5. I'm thinking ahead, I would want to publish these in an ebook format free for use at a time in the future. Anyway, there is no LICENSE file in the repo itself and one should be present (it's pretty standard). The readme has a link to a license not a license itself. Maybe I'm bickering about a non-issue but that's just me.

I've just downloaded the iOS app, it's gonna be my main free time lecture for a while :)

[zenopopovici]

@adaniloff - Those rules look pretty cool. :+1:

[jucrouzet]

Guys, I'm not sure how did I came up in the discussion, but I'm pretty sure it's a bug :) However, interesting exchanges :)

[zenopopovici]

It's my bug :) Sorry.

[tracker1]

Maybe tips should start in _posts/stage0/ wrt initial submission, in this way others can arrange for PRs and once it's been curated can move forward.

• stage0 - Initial Submittion for review (by PR)
• stage1 - Initial Review, accepted as a potential tip topic, edits should happen here pre-release
• stage2 - Content edited, ready for release, prioritization stage

With each git mv through stages, the original and referenced authors should be tagged in the commit message. Not sure if en, or other languages should be separated in the various stages, or if en should be default.

Just some thoughts on this one.

[loverajoel]

@zenopopovici I don't know much about licenses, I like a licence that is free use but for open source projects :smile:

[kurtextrem]

I think we should also define rules such as:

• At least 3 (or 2?) people have to give their "LGTM"
• when there is one 'complaint' resolve first before moving on

I also like standard a lot (@adaniloff suggested it).

[gihrig]

Yes, +1 for Standard JS

[drakmail]

@zenopopovici :+1: I think it is great idea not bounding to a time constant. Another variant – publish only prepared tips once a week. It could provide some regularity without reducing quality.

[adaniloff]

I'm on a meeting today so I won't be able to read / participate, I'll do it later!

Happy to see people who are concerned about jstip :)!

[sjfkai]

Agree with other people's opinions. It's more important to focus on tips' quality rather than must obey "One tip per day".

[bmkmanoj]

@loverajoel - Here is another view to improve the quality of tips. If we can get some of most renowned guys in the JS community to contribute to this project by providing their tips, including the library/framework creators and committers/contributors, the people who drive the EcmaScript and web standards, we can expect the tips to be of high quality. And if we are not able to get them to contribute to this project, at least we can request them to be part of a review panel for the tips, if there is ever one review panel created.

Another way would be to take a look at some of the awesome blog posts written by these people and translate it to tips format and publish them here with their permission/ attribution. This would make sure we can gather the quality content present already in multiple sources and collate them in this repo.

[pastrop]

I think quality is always more important than quantity. The value comes from the output itself and not necessarily from the frequency of its arrival. Also if you you feel like you don't have enough JS in your life, check this one out https://www.codewars.com. It may give you ideas for good tips!

[loverajoel]

@bmkmanoj I tried to contact JS rockstars to contribute but without success yet.

[pastrop]

I will shoot a message to NYC JS group I am member of http://www.meetup.com/NY-JavaScript/

  From: Joel Lovera <notifications@github.com>

To: loverajoel/jstips jstips@noreply.github.com Cc: pastrop pas_trop2003@yahoo.com Sent: Wednesday, February 17, 2016 11:25 AM Subject: Re: [jstips] Rethinking JsTips goal (#251)

@bmkmanoj I tried to contact JS rockstars to contribute but without success yet.— Reply to this email directly or view it on GitHub.

[adaniloff]

It may not be relevant with the main subject of this topic, but I also think one of the greatest thing in a quality > quantity approach is the community which will participate.

Lemme explain my point of view.

Publishing quality means people code to be extremely analysed / reviewed. So people who are going to contribute will share the eager to learn / debate about things they may be not sure about (and not only show to others things they will consider as "true", whatever others say).

Even if there are less tips than 1 a day, that will bring more discussions and PRs, more implication, participation etc from a good community, which will grow bigger AND better (=with better understanding of all JS concepts).

My point is by improving quality, people will want to contribute not only to share but also to learn (I think that is an important quality).

I don't know if this is still relevant with the goal of this subject but I just wanted to share this :).

Hope it will help you to take some decisions about the future updates of this project (the PRs and submissions requests, frequency, quality etc).

Sorry for bad english :).

[bmkmanoj]

@loverajoel That is kinda sad :worried:. I really like this project and I would like to take some responsibility towards keeping it going and grow stronger, by translating some of good stuff from the JS rockstars that I have been collating from blogs/ sites and publish here. If you feel, making me a collaborator will help in this direction - you may do so, but it is fine otherwise also.

[ramitayba]

Simple things are always the best, keep on.

[loverajoel]

All of us are on the same page, quality > quantity. So, I'm going to create a couple labels to tag each tip.

All tips will have (same now) a label tip-proposal to identify tips PR's. Also will be two more labels to identify the status of the tip: under review and ready to merge.

A tip will be ready to merge when at least 5 people give his :shipit: => :shipit:

Also, I need help for somebody that know about licenses, @zenopopovici are right, and the repo don't have a valid license file, and I think that it should contemplate free usage under open source projects, right?

[drakmail]

@loverajoel Are you talking about tips license or about code in tips license? For tips best choice is one of Creative Commons licenses, for code – GPL v3. These licenses best fits for free usage in open source projects.

[loverajoel]

@drakmail awesome! thanks for that!

[zenopopovici]

@loverajoel I've added the license.

[johnstew]

Quality of quantity for sure.

[pastrop]

So, following up on the idea of peer-reviewing  tips before publishing is there going the be some holding area for people to go in and review the pending tips.  How it all is going to work?  Are we going to somehow leverage github workflow with people submitting pull requests?  Also here is yet another pretty amorphous thought.  I am writing scaffolding for ecommerce platofrm using MEAN stack.  While doing it I run into pretty bizarre behavior related to the structure of JSON object (result of the MongoDB database query) that I am sending into my Angular controller via JSON.  It took me over 2 hours to troubleshoot and I bet there are a lot of people out there banging their heads against the wall being faced with the same problem.  This may be too large to be a tip yet it would be useful to share.  Maybe JSTips should allow inputs with people explaining the problem and providing links to their github repos for details 

  From: Joel Lovera <notifications@github.com>

To: loverajoel/jstips jstips@noreply.github.com Cc: pastrop pas_trop2003@yahoo.com Sent: Wednesday, February 17, 2016 4:22 PM Subject: Re: [jstips] Rethinking JsTips goal (#251)

All of us are on the same page, quality > quantity. So, I'm going to create a couple labels to tag each tip.All tips will have (same now) a label tip-proposal to identify tips PR's. Also will be two more labels to identify the status of the tip: under review and ready to merge.A tip will be ready to merge when at least 5 people give his => :shipit:Also, I need help for somebody that know about licenses, @zenopopovici are right, and the repo don't have a valid license file, and I think that it should contemplate free usage under open source projects, right?— Reply to this email directly or view it on GitHub.

[loverajoel]

PR with proposed changes about new rules https://github.com/loverajoel/jstips/pull/260

I need review

[gihrig]

@loverajoel If we're talking about licensing tips code, the GPL is absolutely the wrong license, due to this line at the end of the license file.

"The GNU General Public License does not permit incorporating your program into proprietary programs."

The GPL will ensure that businesses or anyone developing commercial software will not acknowledge using JS Tips (if they're paying attention).

Look around the npm registry and you'll see the MIT is far and away the most common license used in open source JS.

Because MIT is not compatible with GPL, some times a dual license model is used.

If the plan is to offer tips code under any license, contributors need to be made aware of that and explicitly agree to the license(s) used.

On the other hand, if you are only applying the license to the JS Tips site (not the tips code), one of the Creative Commons licenses is probably best.

For more on the various licenses see:

tl;dr leagal Open Source Intiative Wikipedia has a comparison of free and open source licenses. Creative Commons

Licensing can be a sticky issue, hope this helps.

[drakmail]

@gihrig GPL best fits for requirements of @loverajoel

I think that it should contemplate free usage under open source projects, right?

@gihrig you are right, MIT is better as license for tips that allows usage in proprietary projects.

[kurtextrem]

Personally I vote for https://en.wikipedia.org/wiki/WTFPL.

[zenopopovici]

I think GPL should be used. All contributors are volunteers, reviews are done by the same volunteers, it should be open source.

It should be up to @loverajoel though.

We can change the license now, but it will be very hard to do that later.

PS: The license in the repo applies to everything unless we split the repo into 2 different repos (one for tips, the other for the site) and apply a different license to each of them. PPS: The license file type for GLP is plain-text (makes no sense to add .md to it) /cc @loverajoel

[drakmail]

@loverajoel I think there should be a issue with vote for most suitable license for the tips.

[loverajoel]

I have not problems about licence type, we can choose the fittest for the project. The only case that I think that we have to prevent is for example if somebody uses the Tips for creating a platform for tech js and it isn't free.

cc @drakmail @kurtextrem @zenopopovici

[kurtextrem]

Oh yes, totally right. So we need a license which prevents commercial use, and requires crediting when using or modifying the genuine content of the tip (don't confuse the genuine content with actual code - I don't think it makes sense to "license" code in tips, as that would bring confusion whether you have to credit the author when using the code. It's also likely someone else wrote about the same code snippet already) Am 19.02.2016 18:07 schrieb "Joel Lovera" notifications@github.com:

I have not problems about licence type, we can choose the fittest for the project. The only case that I think that we have to prevent is for example if somebody uses the Tips for creating a platform for tech js and it isn't free.

cc @drakmail https://github.com/drakmail @kurtextrem https://github.com/kurtextrem @zenopopovici https://github.com/zenopopovici

— Reply to this email directly or view it on GitHub https://github.com/loverajoel/jstips/issues/251#issuecomment-186307539.

[loverajoel]

@kurtextrem +1

[zenopopovici]

@kurtextrem +1

[loverajoel]

some idea about what kind of license is?

[drakmail]

@loverajoel I think best is MIT license for code in tips and one of of Creative Commons licenses for tips text. It allow to use tips code in free and proprietary projects and restrict tips text usage (for example, allowing usage only with link to jstips repo)

[loverajoel]

I want to merge the new rules, but I need :shipit:'s :p

https://github.com/loverajoel/jstips/pull/260

[zenopopovici]

Suggestion: Can we also set a limit of 2 weeks for an issue to be answered? We would close it if 2 weeks pass and the creator didn't answer. Would help to keep the issue list lean.

[zenopopovici]

Suggestion2: Can we ask people with that have a better implementation of some tip to make a PR? There are some answers in issues that would require a PR, but are left as comments.

[zenopopovici]

Suggestion from #186: We should add JSBin links to tips. I second that!

[sylvaindethier]

I agree w/ @zenopopovici point 2. Why should the tips be translated ? IMO any (JS) developer should be able to read technical english. Is GitHub translated ? No ! Is MDN translated ? ... Oh wait, yes ! But personally I always read their en_US docs.