First Reviewer

answer 1
Yes, but text has to be justified for a more relevant presentation.

May I also suggest the following?
I fully understand – and I agree with - the aim of a Quick Reference Guide, however in my view, 2 options could be studied:

The 1st one is to let pages 1, 2 and 3 as this.

The 2nd one could be:
Just have the logo, Title and Copyright on page 1
Table of Contents on page 2
And Introduction on page 3

this because at a first look, having the Table of Contents on page 2 after the Intro do not ‘seem’ to be coherent (due to the fact that generally, we have the habit to have a Table of Contents before an Intro of a subject).

3. Does the document have an “About This Document” section which allows the end user to get an overview of the state of the document?

answer 3
Yes

4. How completely does the release address the goal of the project? Is the overall document complete in structure and organization? Are any missing or incomplete sections critical enough to keep the document at an Alpha quality level?

answer 4
The document fulfils the aim of being a Quick Reference Guide, but my personal feeling is that something is missing however:

What about the awareness level of the developer supposed to take all these inputs into account?

Indeed, as it is said in the Introduction, this document is presented in a checklist format; and because it has to be handled as a checklist, the 1st check to take into account is to ensure about the willingness of the developer to engage in such a process of checking his own awareness level.

So, to be short, I don’t know what exactly and how to say something about that, but I just wished to raise this to your attention because that could be appreciated afterwards by people reading the Guide.

It’s up to you.

Stable Level

5. Have all the Beta Reviewer Action Items been completed? These will need to be completed if they have not already occurred during a previous assessment.

answer 5
I guess so

6. Have any limitations been documented? Please point out the link(s).

answer 6

7. Does the document substantially address the application security issues it was created to solve?

answer 8
I guess yes about the OWASP Writing Style, but to ensure about Template

9. Have you noted any limitations of the document that are not already documented by the project release lead?

answer 9
Not yet

10. Would you consider using this document in your day to day work assuming your professional work includes a reason to use this document? Would you recommend this document to others in the profession? Why or why not?

answer 10
Yes, absolutely, given that I’ll also recommend this Guide to any outsourced services staff, dev staff, specially for platforms of Services

11. What, if anything, is missing which would make this a more useful document? Is what is missing critical enough to keep the release at a beta quality?

answer 11
I would say the same as answer 4:

The document fulfils the aim of being a Quick Reference Guide, but my personal feeling is that something is missing however:

What about the awareness level of the developer supposed to take all these inputs into account?

Indeed, as it is said in the Introduction, this document is presented in a checklist format; and because it has to be handled as a checklist, the 1st check to take into account is to ensure about the willingness of the developer to engage in such a process of checking his own awareness level.

So, to be short, I don’t know what exactly and how to say something about that, but I just wished to raise this to your attention because that could be appreciated afterwards by people reading the Guide.

Second Reviewer

Second Reviewer

It is recommended that an OWASP board member or Global Projects Committee member be the second reviewer on Quality releases. The board has the initial option to review the project, followed by the Global Projects Committee.

3. Does the document have an “About This Document” section which allows the end user to get an overview of the state of the document?

answer 3

4. How completely does the release address the goal of the project? Is the overall document complete in structure and organization? Are any missing or incomplete sections critical enough to keep the document at an Alpha quality level?

answer 4

Stable Level

5. Have all the Beta Reviewer Action Items been completed? These will need to be completed if they have not already occurred during a previous assessment.

answer 5

6. Have any limitations been documented? Please point out the link(s).

answer 6

7. Does the document substantially address the application security issues it was created to solve?

9. Have you noted any limitations of the document that are not already documented by the project release lead?

answer 9

10. Would you consider using this document in your day to day work assuming your professional work includes a reason to use this document? Would you recommend this document to others in the profession? Why or why not?

answer 10

11. What, if anything, is missing which would make this a more useful document? Is what is missing critical enough to keep the release at a beta quality?