Okie dokie, I think the main page is ready to be called good.

Updated the document to remove the 'maintainer' actions and fix a few typos.

Here's a review of the Contribution Workflow.

Joce,

Firstly, thank you for the detailed review. Also, please remember this is a Contribution Workflow document to help developers understand the high level view of walking their ideas/fixes through to getting onto next/master. Not a detailed how-to.

With that said, let's move on to getting this into a state deserving an ack...

Comment[JL1] - Fixed.

Formatting - Corrected to signify a note.

Comment[JL2] - I hesitate to place links to specifics in a document like this. I sure don't want to maintain them as new versions of installers/tools/operating systems and so-on are released. Adjusted text to refer the reader to use a search engine.

Comment[JL3] - hmmm, not sure what to do with this one. Once an update makes it to proposed or higher the subject is the update, prior to that it communicates the developers state as well.

Comment[JL4] - It seems the removal of that sentence doesn't detract from the document, so it's gone now.

Comment[JL5] - IMO 'Open' happens when there is code to share, even if it isn't a finished solution. Not just that it is being worked on. I believe this encourages the sharing of code, the usage of topic branches, and communication.

Comment[JL6] - Acked and Proposed can not be the same thing. One is prior to the maintainer bringing it into the repository and the other is post.

Comment[JL7] - You are right that hold and invalid are not throughly explained, because, as mentioned, they use their general meanings. And I don't know what adding the word 'mandatory' will do vs. 'it will be'.

Comment[JL8] - I don't think that would fit here.

Comment[JL9] - LOL, yep.

Comment[JL10] - Not sure that there would be a sub-title for this... If so, what would it be? And what would you detail about 'open' as it pertains to understanding the contribution flow. It is simply a change in state.

Comment[JL11] - LH doesn't have voting nor an end-user base to get inspired by.

Comment[JL12] - You mean 'visit lighthouse' to sign-up? Maybe I'm forgetting something, but I don't recall going through a 'set-up' for my lighthouse account.

Comment[JL13] - I don't think there is an actual list, nor do I think there should be one. Experience, desire, and 'fitting in' will get people to where they need to be. Do we really want a group of contributors who always have the attitude of 'Here it is, take it or leave it.' without any considerations? I know I don't.

Comment[JL14] - LOL... That was taken out of the 'Contributor Workflow' doc because I was told it was too specific, and I agree. The what a step by step is for.

Comment[JL15] - This document is not written for people opening bugs, it is written for contributions.

Comment[JL16] - Do you have some keywords in mind? Is it enforceable to layout a set of tags to be used? Would you consider it pedantic to expect someone wanting to contribute something to need to use specific tags?

Comment[JL17 - JL20] - No 'how-to' is discussed here, a 'how' was. A simple explanation of what is happening and what the flow is. And the 'condition' for needs_ack, is exactly as stated in the doc...

...[ needs_ack ] - You have some code ready to be looked at by others and it is posted publicly...

Comment[JL21] - It is called 'an update' for the same reason the 'proposed updates' branch is called 'proposed updates'.

Comment[JL22] - A style guideline would indeed be nice.

Comment[JL23] - Good point. Corrected.

Comment[JL24] - I conciously went with 'needed' instead of 'required' here because 'required' doesn't include so much that in some cases is 'needed'. For example, during a review you may feel that some commenting is needed to explain the reason a function was coded in such a way, but that comment is not required.

Comment[JL25] - Corrected.

Comment[JL26] - The same you that the whole document is written to, the person contributing and desiring to have a high level understanding of the flow.

MISC -

• The periods at the end of the header/subject lines are there for markdown.
• 'The tickets with' -vs- 'Tickets with' -- not sure which is proper english here...

Thell,

• Comment[JL20] should still be fixed IMO. You bunched it with the "how-to" discussion while it's a question of grammar.
  
• As for the 'The tickets with' -vs- 'Tickets with', Word says the one without the "The" is a fragment, as the one with the "The" isn't.

However, you're the native English speaker and I'm not. What do you think?

Also, after verification, the dots ('.') are not needed at the end of the titles with markdown.

Here's my review for the Detailed Example Contribution.

Comment[JL20] - ah, missed that dupe. Corrected.

Also, after verification, the dots ('.') are not needed at the end of the titles with markdown.

Huh, where in the world did I get that idea then, could've sworn format styles bled over when I removed them before. Anyhow, they are removed.

Thanks again for taking the time to review that.

Detailed example review:

Comment[JL1] - A 'How to install git and setup putty' doc? No, and as nice as that would be I'm not sure if installing git tools is a problem for anyone. SSH setup on the other hand seems to be a problem for some and I have tried to isolate some of the issues and they keep eluding me.

Comment[JL2] - Yes, '-'s should be used, I changed it to initials/LH-ticket#/topic-description

Comment[JL3] - I've added it lower in the document after pushing the v2 branch up and at the end after seeing it has been merged to master.

Comment[JL4] - Yes, link added to the Lighthouse support page.

Comment[JL5] - Yep, git add to stage the changed document.

The rest of the document was already changed from the version reviewed.