-
Notifications
You must be signed in to change notification settings - Fork 730
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
Troubleshooting and help about unix commands is quite scattered #773
Comments
I've been thinking about this too, and also want to pull @Kdisimone to the discussion as well. I think there are some other general re-organization pieces to be done, in addition to better setting up from the beginning about expectations, basic understandings of how a closed loop works, etc. But in general - yes, I wouldn't mind gathering up the various troubleshooting sections. |
Yes...I agree. I think this would be a great component to a more general re-org. I think @danamlewis have been having some initial ideas on that too in recent conversations. This would be a good part to add to that broader reorg. For example, I think moving NS site setup in the Phasing order may be a good idea...since once people get rolling on their edisons, it is a bit inefficient when they may stop and come back to work on Phase 2. I'd love to have an intro section which has something akin to Preparations for OpenAPS which would include NS site updating, wifi network identifications, cell phone plan investigation, basal testing, reading up on advanced features, etc. So that when people actually start to build their rig...all the homework has been added to a "prep sheet" if you would so that they aren't making it up on the fly and thereby adding potential to make mistakes. |
@Kdisimone and @danamlewis . I think most of this has been done with your re-org. |
Yesterday with my pull request #772 I noticed that the troubleshooting and help about unix commands is quite scattered in multiple pages in the docs.
Wouldn't it be a good idea to organize the troubleshooting more based on the interfaces, e.g.
etc.
Before I start, I first wanted a discussion, because I think this is quite some refactoring work to make it good.
@scottleibrand and @danamlewis : what's your take on this?
The text was updated successfully, but these errors were encountered: