Open Harry-Torry opened 8 years ago
I want to include things such as the hidden helpers (object, array, data_get etc). live templates for phpstorm and generally the things that get posted into frontporch daily.
I'd like to take a stab at a more broken-down and detailed version of the official docs, maybe with a focus on common pitfalls and best practices/considerations for each. daux.io looks interesting, would it just be hosted on github?
GH Pages provides more than enough for what we want to do with this :stuck_out_tongue:
I'd like to take a stab at a more broken-down and detailed version of the official docs, maybe with a focus on common pitfalls and best practices/considerations for each.
Hell, sometimes a proper example would just be enough!
Perhaps we could take the existing docs and work from there? On 23 Feb 2016 12:48, "Harry Torry" notifications@github.com wrote:
I'd like to take a stab at a more broken-down and detailed version of the official docs, maybe with a focus on common pitfalls and best practices/considerations for each.
Hell, sometimes a proper example would just be enough!
— Reply to this email directly or view it on GitHub https://github.com/larachat-frontporch/laravel-5-unofficial-docs/issues/1#issuecomment-187686138 .
That sounds like a big task in terms of keeping it up to date. Are we then wanting to support 5.1, 5.2 and 5.3 at the same time?
IMO it'd be better to start fresh, and being an addition to the official docs, rather than trying to replace them. Targeting only the newest version might be the better option here (and perhaps the LTS ones?). It would encourage people to use the latest version of laravel and at the same time force us to rediscover new things and not fall behind.
Great idea, I agree with @thomasruiz on this one. Target the most recent version(s) first, move on to the LTS ones later.
I don't think we should take the existing docs and go from there, that'd only add overhead (reading docs, seeing what's wrong with them, correcting them). We can definitely take "inspiration" from them though :smile:
Taking the existing docs isn't the goal. Dont we want to create a place to find common problems and solutions?
I would say we do it like @thomasruiz said. Also add a section for common used code snippets from larachat.
Let's get the ball rolling!
To be clear, my take of the docs isn't a rewrite of the docs, it's more like a deconstruction of how the components act and behave with each other, a "behind the scenes" look if you will, intended to help people who want a deeper understanding of how things work instead of a cookbook. It'd probably need a fresh structure, because going from the old one would make it all too easy to repeat the old mistakes...
So how do we plan to structure this documentation? And what exactly do we want to put in it? It would be great to have a list of subjects that we must have, then some that we should have, and others that we could have. That'd make the decision process better.
To get back to this... I'd love to see some of the more obscure changes that aren't in the current documentation, like the getRouteKey()
method on your models, or a $with
property to always eager load.
Should the docs be written in markdown and hosted here on GitHub or should we put it on its own website and see what to do from there?
lets do it first of with markdown, and if it gets big, we can still switch to a website
I'm gonna spend some time on this.
Just building upon the actual documentation with things that are ignored to help newer devs.
Any tips on directions or anything?
I'm looking at http://daux.io/Features to generate the site.