@shettygururaj as discussed here are some notes for the energy gateway blueprint context, uses cases as well as notes on the building.
Context:
The energy distribution market is undergoing transformations nowadays
(producers, consumers, distributors etc). To accommodate these
changes to the global energy market, the utility provider and home owners
need a way to enhance the interaction between the grid and the household.
This Blueprint builds a residential energy gateway, to gather local energy
data, provide insight of energy usage in the home. The data will be displayed
on a local web dashboard and leveraged locally, as well as, online resources
for energy management.
Use Cases:
The Residential energy Gateway Blueprint, to be ready with the Goofy GA in
December 2022, will cover the following use cases:
Data collection of local energy consumers and producers (PV, electric vehicle,
heat pumps, HVAC, appliances, smart plugs, etc).
To collect this data Oniro will be extended to support the Modbus RTU and TCP
protocols as well as the upcoming Matter standard.
Energy Management rule-set based on collect local data, PV energy forecast and
grid energy pricing.
Building and flashing:
Usual Goofy Pi4 build instruction with two additional layers:
@nawab So you massaged the file into rst format and did some editing. But you want me now to raise the MR?
I think we have misunderstanding here how the documentation process works. I was under the impression that I would give this kind of inout file (as above) to @shettygururaj and he would work out the full docs. The above is really only notes and need a lot more work to be full docs.
If you expect me to do the docs myself and you review and doing editorial changes we could skip this whole input file dance I and I would just assign these issues to myself and not the doc team and loop you in whenever I have a MR ready to be reviewed.
I don't know what made you to comment like this, I am sorry if we have done any thing unparliamentary, that made you to give such weird expressions, but we haven't only done editorial things only. We have structured the document the way it must be, added the necessary introduction and maintained the coherency in the flow and checked language, & lastly to a correct format, then with MR we proceed further.
I added this to take a shape of RST file, where you could raise an MR & we can further discuss on shortcomings as you comment & point us to right resources to read & add to the file.
On a lighter note, I have a question, how is @shettygururaj expected to know what you know about a new feature precisely? He may be good technically to understand code that you write, terms that you use & understand things that you give. But how are you expecting him to do extensive research and produce a document?
We in documentation team do know our things very well, @shettygururaj having over 15 years of experience & worked for many conglomerates, doesn't he know how to go about documentation? such derogatory remarks of yours demotivates us, we have always loved to work with right attitude.
The universally accepted documentation process is as follows:
Input draft is given by respective feature developer.
It is then taken by docs team, add necessary information as follows:
Input draft (Stake holder/developer)
Stage 1: Content creation & curation (Docs Team)
SEO/ Add Meta information
Add Introduction
Document Layout
Content structure
Add content/ edit content
Check Semantics
Syntax
Transcribe to correct format
Intermediate output:
(Stakeholder/Developer)
Developer to raise MR with the correct formatted file
Stage 2: Content review & approval
(Docs Team with collaboration of Stakeholder/Developer)
Review Cycle (internal & external/developer)
Ensure style guide is followed
Fix Review comments
Developer approval
Fix any left overs
Docs team approval
Publish online
Repeat steps after Content Structure until & unless docs & dev teams are fine with the output.
For the build instructions we need to coordinate with @pidge to avoid duplication. The checkout flow might also change as the blueprints are supposed to be the root and oniro core and other layers come through submodules.
To further work on this please raise a MR request so we can really review the individual lines and comment on them.