Proposal to update the description of the Design Quality Review (Consulting?) subgroups

[qwertyone]

The Problem

Currently the text of groups.md seems vague to the process of how the design quality review groups work. It has identified the different fields that are involved in Daemo and seemed to provide 'generic' functions normally associated with the specializations. The scoping of fields was identified by an article shared in the previously related proposal, which is a necessary step in developing the quality groups. This, however, is not the intent of the Review Group, which was noted after consensus was reached. Proposal #50 received no timely feedback during the proposal review process of 9 days, when consensus is able to be broken and actions written in the proposal were carried out.

The quality review group as intended is expected to change over time to meet the needs of the group. As a review group for the 'Collective', their efforts will be limited to the following one or all four consulting functions: verification, validation, review, and auditing.

The Proposal

The resulting description will change the current wording in the document from:

Graphic Team
Graphic creates and iterates the assets and collateral that establish the identity of Daemo across media and technology. To members of the community, the members of the quality review team that are identified as members of the graphic group become the mentors and teachers of the community about the Material Guidelines and that presentation materials adhere to Daemo’s style guide. They help to guide members in the development of graphic assets for conference presentations, submitted publications, and the software visual look across phones, laptops, desktops, and other media devices identified by the User Experience team. These members are responsible for maintenance and submission of the graphics to github, as well as maintaining a components library of icons, logos, etc. from 3 competitive platforms on the Crowd Research Wiki.

Deliverables: graphic re-draft, written feedback to members submitting graphical changes to the team, wire frames and mock ups across media and devices, written validation of developed media to the Daemo standard and other relevant standards required by ... Pixel Perfect Daemo Resources.

Collaborative Tools used by members: Figma, Slack, Github...

to something along the lines of the following to be inserted in groups.md:

Graphic Team

To members of the community, the members of the quality review team that are identified as members of the graphic group become the mentors and teachers of the community about the Material Guidelines and that presentation materials adhere to Daemo’s style guide. They help to guide members in the development of graphic assets for conference presentations, submitted publications, and the software visual look across phones, laptops, desktops, and other media devices identified by the User Experience team. These members are responsible for maintenance and submission of the graphics to githubThese members are responsible for approval and merge of final submission of the high fidelity graphics in the master branch of github, as well as maintaining a components library of icons, logos, etc. from 3 competitive platforms on the Crowd Research Wiki.

Deliverables able to submitted to review for the team: graphic re-drafts, detailed wire frames and mock ups across media and devices,

Deliverables submitted from the review team to submitters: written feedback to members submitting graphical changes to the team, written validation of developed media to the Daemo standard and other relevant standards required by ... [to be added in future iterations]

Collaborative Tools used by members: Figma, Slack, Github... [to be added in future iterations]

This will be repeated with both User Interface and User Experience Groups by the second week of February. The changes will be written in this issue for review.

Implication

The Design Quality Review Group will be more aligned with being a review group. Groups.md will be updated and more complete for future members of the collective.

Side Notes: proposal 50 has elections for members with service constraints. If these are at issue, please post. Quality teams are limited in size by practice.

Addendum: The wording of this text will be subject to revision as necessary as determined by the members of the teams upon introduction into the governance documents.

---

Use comments to share your response or use emoji 👍 to show your support. To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.

[shirishgoyal]

These members are responsible for maintenance and submission of the graphics to github

I think above should be changed to

These members are responsible for approval and merge of final submission of the high fidelity graphics in the master branch of github

[qwertyone]

Thank you Shirish! I will follow this same approach on GitHub with the other groups. What other things must this group do you think?

…

On 18 January 2018 at 19:14, Shirish Goyal ***@***.***> wrote: These members are responsible for maintenance and submission of the graphics to github I think above should be changed to These members are responsible for approval and merge of final submission of the high fidelity graphics in the *master* branch of github — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFy3xkrrp_rvrevVkcQ_OqUN8vbN1EmPks5tL4oIgaJpZM4RjVol> .

[qwertyone]

User Experience Group

General
The User Experience group within the Design Quality Review Team focus on the Human Behavior aspect of the platform. They host Daemo work models and the general user requirements specifications.
Community Competitiveness
As an outcome of their emphasis on human behavior, this team maintains relevant deliverables within a shared and private to the Quality Review Group Google Drive folder (This is considered competitive research for the platform and should not be readily public), of which access to this folder will be allowed during service. _The Ux team will also be responsible for maintenance and reporting of user competitive performance benchmarks between competitors such as predicted TLX workload and complaints review from TurkOpticon. From these reports, they will suggest to the community studies for members to lead and further.
Community Participation
_ They assist members of the community to have projects and deliverables that accurately reflect items in this private collection and serve, in different roles and capacities of their own will, as mentors, participants, and assistants of proposed projects that align with the platform leadership team's priorities. These capacities will be updated (deleted as well as elaborated) by members of the team as new members join in.

Deliverables able to submitted to review for the team: work interaction models, chosen research method, analytical methods, experimental analysis results, click through prototypes, questionnaires, user requirement specifications, user cases, personas... [adjusted as necessary]

Deliverables submitted from the review team to submitters: written feedback about submitted materials, signals of interest to either mentor, assist, or participate in a proposed project, small scale prototype studies to validate research and analytical methods, formal instructions and resources related to the domain of the study, written feedback on how to align proposals to the materials maintained in the Google Drive folder, critiques on the methods of submitted proposals

Collaborative Tools: Figma, Slack, Google Drive, CoLab, UX component library (behavior patterns of users)...

[qwertyone]

User Interface Group
General
The User Interface Group focuses on the pages and screen flow of the Daemo Platform. If the UX group defines User Requirements, the UI Group optimizes the requirements with the interface and informs the Ux team of the practicality of the requirements. This group is responsible for the maintenance of the UI library and will be responsible to post major changes to the Daemo interface to the main branch of Github. For the Daemo community, this team will maintain a design pattern library from 3 competitive platforms on the Crowd Research Wiki, which will be maintained on a Google Drive folder that shares access with the UX team.
Community Competitiveness
The UI team will also be responsible for maintenance and reporting of model based competitive performance benchmarks between competitors such as predicted timings and workload. From these reports, they will suggest to the community studies for members to lead and further. For members in the community the UI group communicates with front end engineers regarding the feasibility of proposals and returns to proposal submitters feedback about their submission.
Community Participation
They assist members of the community to have projects and deliverables that accurately reflect items in this private collection and serve, in different roles and capacities of their own will, as mentors, participants, and assistants of proposed projects that align with the platform leadership team's priorities. These capacities will be updated (deleted as well as elaborated) by members of the team as new members join in.

Deliverables able to submitted to review for the team: mock ups, design patterns, template layouts, UI studies, A/B tests

Deliverables submitted from the review team to submitters: provide written feedback to members on related proposals, mock ups with layout changes, corrections of priority proposals to fit current Daemo standards, feedback on UI studies and A/B testing methods, analytical methods and statistical interpretation...

Collaborative Tools: Figma, Slack, Google Drive, CoLab, UI component library...

[neilthemathguy]

Thanks! Can we discuss this further over the hangout in upcoming week?

[qwertyone]

Often times, the meeting times are in conflict with my schedule. I am okay with written correspondence however. I am sure that you can break consensus to delay the process until it fits the groups needs. I will break consensus as well if the meeting attendance is truly important so that we can address this and find a time for review. :-)

…

On 22 January 2018 at 15:47, Neil Gaikwad ***@***.***> wrote: Thanks! Can we discuss this further over the hangout in upcoming week? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFy3xvqP3QRNH_PuNE6o8QnBF0OpuUomks5tNJ-dgaJpZM4RjVol> .

[qwertyone]

Also, I was hoping that this would be an iterative process. I think that you are able to edit the text directly to address the issues as you see them, and these changes are not maintained in Github if they are in the same comment.

…

On 22 January 2018 at 15:51, A. G. ***@***.***> wrote: Often times, the meeting times are in conflict with my schedule. I am okay with written correspondence however. I am sure that you can break consensus to delay the process until it fits the groups needs. I will break consensus as well if the meeting attendance is truly important so that we can address this and find a time for review. :-) On 22 January 2018 at 15:47, Neil Gaikwad ***@***.***> wrote: > Thanks! Can we discuss this further over the hangout in upcoming week? > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#53 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFy3xvqP3QRNH_PuNE6o8QnBF0OpuUomks5tNJ-dgaJpZM4RjVol> > . >

[neilthemathguy]

Yes, it is iterative process and consensus breaking is not for delaying the process. Before merging above descriptions into the governance documents, they should be discussed. It is important to get other's participations and view points on this.

Separate hangouts that suits to your and other people's times can be organized to discussed this further.

[qwertyone]

I agree.

…

On 22 January 2018 at 16:01, Neil Gaikwad ***@***.***> wrote: Yes, it is iterative process and consensus breaking is not for delaying the process. Before merging above descriptions into the governance documents, they should be discussed. It is important to get other's participations and view points on this. Separate hangouts that suits to your and other people's times can be organized to discussed this further. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFy3xikcVLnI3AK7xSnuixnpSoh6955Eks5tNKLagaJpZM4RjVol> .

[qwertyone]

@neilthemathguy Why did you add the needs information label?

[neilthemathguy]

There are multiple things unclear and need further details in above description I'll add them once I'm back or happy to discuss on hangout. (e.g., the platform leadership team--- we don't follow the leadership model, everyone is a leader by actions).