Dear OpenEEmeter users:
I wanted to follow up on this feedback meeting. Special thanks to those who showed up to give feedback and contribute to the discussion. I wanted to share minutes from the meeting (copied below) and note improvements we are releasing today in response to the discussion we had.
We've added a new tutorial which shows how all the pieces of the library fit together, which is available here: http://eemeter.openee.io/tutorial.html. We'd love for folks to check out this tutorial and offer feedback or improvements. If anyone finds issues in the new tutorial, please feel free to either 1) respond to this message 2) create a github issue) or 3) create a pull request to fix it.
We invite other users to take a look at this list of suggestions and add their votes, voices, and contributions.
All the best,
Feedback from Sept 4 documentation feedback meeting (also recorded in wiki):
- Hourly methods documentation needs to be bulked up.
- For instance, how do all the pieces fit together?
- There seemed to be some specific trouble with a eeweather string method, as well as inconsistency between functions.
- How do users report issues and share feedback about consistency of library functions?
- Would be great to have more examples of code usage inline.
- One user needed to figure out the outputs manually by running the code.
- There are lots of functions in eeweather that do just one thing - can they be bundled into single functions or at least into sections in the documentation?
- It would be great to have links to the raw public sources? (such as TMY3) this is a little bit obscure and difficult to find in the existing methods.
- One user developed a bridge from the WBAN codes to other codes, like NCDC codes, USAF_ID, ICAO.
- Could this be a possible contribution?
- Along these lines: having “Quick steps” for how to make contributions would be helpful to potential contributors. We need to make this as easy as possible if we want it to happen
- Could be helpful to add more context and background on actual/performance vs normal year savings, including definitions of terminology and internal/external consistency in using these definitions.
- How do we know how users are using the library and what they are struggling with?
- Integrate the tutorial into the documentation and make it easily available inline
- Schedule specific follow ups or working sessions to work through specific issues
- Write definitions of flavors of savings or include these in the documentation
- Be more clear about how users report issues, share feedback, and offer contributions.
- Have a place to post a "show and tell" of things users have accomplished using the library, or features they have developed for their own use. This would give us a way to tell how people are using the library and where the gaps are in the current library functions.