Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure docs are updated for current code. #72

Closed
lonnieezell opened this issue May 6, 2016 · 14 comments
Closed

Ensure docs are updated for current code. #72

lonnieezell opened this issue May 6, 2016 · 14 comments
Assignees
Labels
documentation Pull requests for documentation only
Milestone

Comments

@lonnieezell
Copy link
Member

lonnieezell commented May 6, 2016

Need to make sure the docs match up to the current state of code. While I've got a couple of people assigned to this task, feel free to send PR requests for docs if you want!

@lonnieezell lonnieezell added this to the Phase 1 milestone May 6, 2016
@lonnieezell lonnieezell added the documentation Pull requests for documentation only label May 9, 2016
@lonnieezell lonnieezell changed the title Ensure docs are update for current code. Ensure docs are updated for current code. May 9, 2016
@jim-parry
Copy link
Contributor

jim-parry commented May 26, 2016

Remaining to do:

  • Update session writeup in user guide
  • Update contribution guide
  • Move reference docs from user guide to API docs ... agreed to leave this for now
  • Contrast our style guide vs PSR-1 and PSR-2
  • Contrast our loading vs PSR-4
  • Document security practices plan <"real" doc is separate issue for pre-alpha 2>
  • Document the roadmap or the roadmap process -> JLP
  • Document "Running from the CLI"
  • Document "Managing Multiple Applications"
  • Document "Multiple Environments"
  • At least a simple writeup on CI4 "internals", to guide contributions
  • Rework the "Upgrading from 3.x to 4.x page" in the installation section

New docs needed:

  • Debugging - Kint and the Debug Toolbar
  • Content Negotiation
  • Headers in Incoming Request
  • Security library (CSRF)
  • Headers in Response
  • Content Security Policy in Response
  • Uploaded Files (FileCollection and UploadeFile classes)
  • URI library

@lonnieezell
Copy link
Member Author

I added a couple of the pages that need to be written to that list, just so that we can keep it to a single spot.

Over the last week or so, I've been going through each page from the top down trying to ensure it all matches the current stuff, plus has consistent formatting with certain things (like bold for file paths), and writing additional pages that don't yet have content.

Oh - and FYI- we should be 100% compatible with PSR4 autoloading. If not, let me know and I'll tweak, but I'm pretty sure we are.

@jim-parry
Copy link
Contributor

jim-parry commented May 26, 2016

Good to see additions! :)
I suspect we are compatible with PSR-4, but with our own extensions, and I think that merits explanation.

@lonnieezell
Copy link
Member Author

I suspect we are compatible with PSR-4, but with our own extensions, and I think that merits explanation.

Good point. Also, we should probably have something that describes the file-naming scheme. I'm sure that exists in the CI3 docs somewhere but don't think there was ever a single spot that said, "This is how it's done and why".

@lonnieezell
Copy link
Member Author

I've added the Multiple Environments docs, but it wouldn't hurt to revisit this and expand a little bit in the future with a little bit more of a tutorial feel.

@lonnieezell
Copy link
Member Author

What type of information were you thinking of in the "internals" guide?

@jim-parry
Copy link
Contributor

I am pretty sure that everything will need revisiting!

"Internals guide" ... basically what a developer would need to know, beyond the style guide, to create a package/class or extend one

  • namespace conventions (do we have specific places we want to put stuff?)
  • how such a package would fit in (eg updating Config\AutoloadConfig?)
  • unit testing expectations (eg all public or protected methods, not just "how to", which is in tests/readme)
  • interface/abstract/concrete class expectations/guideline?

@lonnieezell
Copy link
Member Author

I'll tackle the internals guide, then, unless you wanted to to become more familiar with it.

@jim-parry
Copy link
Contributor

That would be great, thanks :)

I am reviewing the other new pages, and plan to add some caveats & dire warnings to the main readme :-/

@lonnieezell
Copy link
Member Author

The internals page is in place now. I've got some more work to do on existing "Libraries" but we're getting close!

@lonnieezell
Copy link
Member Author

Well drats. :)

I just went through the code and tried to match everything up and make sure it's been discussed, and found 8 more things that need documenting. Most of them are from scratch, but there are a couple we can take from CI3 and modify.

I'll be on vacation from June 8th-13th so it might not be until end of the month before we can do the "pre-alpha" release.

@jim-parry
Copy link
Contributor

Good catch! Better to catch it now rather than once it is out the door :-/
If the "pre-alpha" isn't ready until the second half of the month, so be it.
Thank you so much for all your hard work!!
I will continue to chip away at my end. I won't be going away on vacation until August, but I have some heavy workshops June 7-14, which will cramp my availability.

@lonnieezell
Copy link
Member Author

I've wrapped up the last of the docs items. At least, it's all good enough for now. :) The upgrading page can wait because a) we don't want to encourage it and b) I think this will be a completely different sort of upgrade guide...

@jim-parry
Copy link
Contributor

Alright! A few more loose ends and we should be ready to wrap pre-alpha1!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Pull requests for documentation only
Projects
None yet
Development

No branches or pull requests

2 participants