The docs are licensed and maintained under the same Organisation as the code is.
And the Organisation decided to require a sign-off at some point.
I would say that the docs repo handles already most of the sign of statement exceptions within the Organisation.
But with my current information level i am not able to omit the sign-off statement completely for large edits.
Maybe you could finde someone who is willing to transfer improvements from here to github, but that’s of course some effort that would have to be made on top.
Indeed - I wouldn’t want to burden anyone with that at all!
As I say, I’ve never seen anyone else mention this as a barrier to entry so if you lift the restrictions you might only gain one extra contributor: might not be worth the headache!
For anyone who reads this thread, don’t sweat it, just do it, use the web interface the first time, follow the directions and Jerome will help you!!! He helped me make my first pull request and I screwed it up and he was super patient with me and taught me how to do it
Just kidding.
We are all here in our free time and to get some progress.
Thats the common goal and thats how we should treat each other.
@Bruce_Osborne
You got me a bit with that openhabian thing so i checked it and the effort needed wasn’t that much.
@hafniumzinc
I am handling the sign-off very loose also, when there are 5 or 6 oneliner changes.
So there is stil somepthing possible.
I would not accept that if there was a complete article rewrite.
The thing documentation for ZWave is a special script indeed.
But the solution is pretty simple.
You are able to add docs with the site posted above but finally they will end up in the ZWave binding repository, whre we will fetch all docs pages.
For Things the documentation must be in the database where a script builds the text for export to gitHub. Otherwise any changes there will eventually be overwritten. I help write that script for the new database site. @chris can verify this,
Correct - any documentation related to things must be made in the database entry for that thing to avoid it being overwritten when a database export is performed. General docs (ie in the README) can be made directly as a PR in GitHub.
Each device has a field in the database for usability information (I forget the exact name) - this is where we can add anything that user might want to document about a device.
Please dont tread things in my posts that have not been written there.
I explained how the documents end up in the website and never gave any advice at some point to edit in a different way than done now.
Sorry - I had not read he whole post and was just answering a question that someone specifically asked me!!
That said, you raised the question of ZWave only 2 posts ago, so I actually don’t see what is wrong with this clarification since clearly things are different your ZWave than other bindings.
I was trying to add the actual source for the thing data because I assumed you were not aware and I wanted to assist with accuracy for the end user. I my opinion a user would get confused and frustrated if they made he change in GitHub and then found it later reverted.
Sorry for my attempt at helping. Feel free to ignore.
There is a section in the README about the ZWave database - it probably doesn’t specifically mention documentation so could possible (as always ) do with improvement. Likewise at the bottom of each thing doc page there is a “found an error, or think of some improvements” type link to the database for the specific thing, so it’s reasonably well documented (I think) - or at least we’ve tried to make a reasonable attempt to document it but I’m open to improvements
If you want to discuss each and every documentation issue, feel free to do so. But someone who is capacle should adjust the title accordingly. Or i can do for you. Just let me know the title.
Sorry @yab looking back it was maybe not the best discussion to takeover your topic.
I can open an dedicated one, if the notifications get a bit overwhelming.
Not a problem for me, maybe you got me wrong. But reading the title i’d not expect the discussion we have now. Easiest solution seems to be (for me) changing the title.
) do with improvement. Likewise at the bottom of each thing doc page there is a “found an error, or think of some improvements” type link to the database for the specific thing, so it’s reasonably well documented (I think) - or at least we’ve tried to make a reasonable attempt to document it but I’m open to improvements