Community Meeting ( April 14, 2023 ): Primer: Baby Bliss Bot

[Justin Obara]

At this week’s Community Meeting 

 ( April 14, 2023 ) Shirley McNaughton will be leading a Primer on Baby Bliss 
Bot. Please note the special time and date for this community meeting.

Description:

Hour One

History of AAC/Educational Application of Blissymbolics, 1971-2023

'Bliss' Community and Teaching of Blissymbolics, 1971-2023

Important features of Semantography (Blissymbolics} as we teach the language 
and develop vocabulary today

10 minute break

Hour Two

Take the Time -  Kari’s song

Exploring possibilities for Baby Bliss Bot - an Educator’s Perspective

Group Assignment and Sharing

Questions, Answers, Discussion 

Reference
blissymbolics.org 

Time:
1:00 - 3:00pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions follow the Fluid and Inclusive Design Community Code of Conduct 
.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Design Crit ( Mar 28, 2023 ) - Paper Playground - Interactive Interaction Design Space

[Justin Obara]

Reminder about the community meeting this week (Mar 28, 2023) from 2 - 3pm ET. 
Topic is Paper Playground - Interactive Interaction Design Space.

Thanks
Justin

> On Mar 20, 2023, at 1:16 PM, Justin Obara  wrote:
> 
> Sorry for the inconvenience, this meeting will be postponed 1 week to Mar 28, 
> 2023 from 2 - 3pm ET.
> 
> Thanks
> Justin
> 
>> On Mar 20, 2023, at 8:13 AM, Justin Obara  wrote:
>> 
>> There will be a Community Design Crit on Mar 21, 2023, 2pm to 3pm ET.
>> 
>> Topic: Paper Playground - Interactive Interaction Design Space
>> 
>> Description:
>> 
>> From the Inclusive Design team at PhET Interactive Simulations: A co-design 
>> tool and integrated space to collaboratively design multimodal interactions. 
>> A design space that allows for mapping physical space to design parameters, 
>> detached from standard interaction patterns for web components/design.
>> 
>> Who: anyone exploring the design of something interactive
>> What: an environment that combines both virtual and physical design spaces - 
>> hopefully for rapid prototyping of multimodal interactions
>> Why: to fill a need for a new kind of co-design space/tool
>> 
>> 
>> Facilitator: Taliesin
>> 
>> Meeting Details:
>> 
>> Date: Mar 21, 2023
>> Time: 2pm to 3pm ET
>> Virtual Meeting : zoom 
>> <https://ocadu.zoom.us/j/82743278568?pwd=KzQ0Nkc2R1lSYllhVFk1d1lQUDJSdz09>
>> 
>> Other Information:
>> 
>> Please visit the Inclusive Design Critiques and Workshops 
>> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>>  wiki page, for more information including the schedule of upcoming events. 
>> 
>> Contributions are licensed under Creative Commons Attribution 4.0 
>> International License <https://creativecommons.org/licenses/by/4.0/> and 
>> follow the Fluid and Inclusive Design Community Code of Conduct 
>> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>>  (Note: some demonstrated/presented or discussed software, hardware, 
>> research, tools and etc, may have their own license.)
>> 
>> Thanks
>> Justin
> 

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Design Crit ( Mar 28, 2023 ) - Paper Playground - Interactive Interaction Design Space

[Justin Obara]

Sorry for the inconvenience, this meeting will be postponed 1 week to Mar 28, 
2023 from 2 - 3pm ET.

Thanks
Justin

> On Mar 20, 2023, at 8:13 AM, Justin Obara  wrote:
> 
> There will be a Community Design Crit on Mar 21, 2023, 2pm to 3pm ET.
> 
> Topic: Paper Playground - Interactive Interaction Design Space
> 
> Description:
> 
> From the Inclusive Design team at PhET Interactive Simulations: A co-design 
> tool and integrated space to collaboratively design multimodal interactions. 
> A design space that allows for mapping physical space to design parameters, 
> detached from standard interaction patterns for web components/design.
> 
> Who: anyone exploring the design of something interactive
> What: an environment that combines both virtual and physical design spaces - 
> hopefully for rapid prototyping of multimodal interactions
> Why: to fill a need for a new kind of co-design space/tool
> 
> 
> Facilitator: Taliesin
> 
> Meeting Details:
> 
> Date: Mar 21, 2023
> Time: 2pm to 3pm ET
> Virtual Meeting : zoom 
> <https://ocadu.zoom.us/j/82743278568?pwd=KzQ0Nkc2R1lSYllhVFk1d1lQUDJSdz09>
> 
> Other Information:
> 
> Please visit the Inclusive Design Critiques and Workshops 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  wiki page, for more information including the schedule of upcoming events. 
> 
> Contributions are licensed under Creative Commons Attribution 4.0 
> International License <https://creativecommons.org/licenses/by/4.0/> and 
> follow the Fluid and Inclusive Design Community Code of Conduct 
> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>  (Note: some demonstrated/presented or discussed software, hardware, 
> research, tools and etc, may have their own license.)
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Mar 21, 2023 ) - Paper Playground - Interactive Interaction Design Space

[Justin Obara]

There will be a Community Design Crit on Mar 21, 2023, 2pm to 3pm ET.

Topic: Paper Playground - Interactive Interaction Design Space

Description:

From the Inclusive Design team at PhET Interactive Simulations: A co-design 
tool and integrated space to collaboratively design multimodal interactions. A 
design space that allows for mapping physical space to design parameters, 
detached from standard interaction patterns for web components/design.

Who: anyone exploring the design of something interactive
What: an environment that combines both virtual and physical design spaces - 
hopefully for rapid prototyping of multimodal interactions
Why: to fill a need for a new kind of co-design space/tool


Facilitator: Taliesin

Meeting Details:

Date: Mar 21, 2023
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Mar 7, 2023) - Accessible design collaboration tools

[Justin Obara]

There will be a Community Design Crit on Mar 7, 2023, 2pm to 3pm ET.

Topic: Accessible design collaboration tools

Description:
Look at and discuss options for accessible design collaboration tools.  

Facilitator: Lisa & Cheryl

Meeting Details:

Date: March 7, 2023
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Feb 7, 2023 ) - ChatGPT Accessibility test/comparison

[Justin Obara]

There will be a Community Design Crit on Feb 7, 2023, 2pm to 3pm ET.

Topic: ChatGPT Accessibility test/comparison

Facilitator: Lisa Liskovoi and Maysa Borges Gama 

Meeting Details:

Date: Feb 7, 2023
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Dec 13 ): Eudaemonic Design as a Co-created Approach to Health and Well-being: An Exemplar Case with Older Adults at Home

[Justin Obara]

At next week’s Community Meeting 

 ( Dec 13, 2023 ), Jenna Mikes will be talking about Eudaemonic Design as a 
Co-created Approach to Health and Well-being: An Exemplar Case with Older 
Adults at Home.

Description:

Home is central to who we are as humans. It shapes us. At a time when 
COVID-19-related physical distancing has prompted a global live/work/play from 
home pervasiveness, there is a growing demand to conceptualize how homes can 
encourage flourishing health and well-being. Developing this understanding is 
especially necessary when contemplating the impact on vulnerable demographics, 
such as the rapidly growing older adult population who desire to age-in-place 
but do not necessarily have the infrastructure and support needed to do so. 
Based on co-designed futuring activities conducted with older adults and 
designers, this research focuses on understanding what a flourishing home could 
look and feel like when building on the neo-Aristotelian concept of eudaemonia 
(literally defined as eu (good or health) + daimon (true self)), which 
correlates to people being the best versions of themselves. Eudaemonic 
well-being has evolved in the field of psychology as a means of proactively 
designing for flourishing health and well-being via Self Determination Theory, 
but it has yet to be explored in a built environment context. By considering 
eudaemonia as a worldview, this research examines how home-based design can 
prompt optimal health and well-being—not only by applying the resulting 
Eudaemonic Design model and principles to the home environment but also by 
following a respectful design approach to precipitate virtually-engaged 
participants to feel empowered, experience agency, and act as their best 
eudaemonic selves.

Time:
2:00 - 3:00pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Nov 29 ): Human-robot interaction for inclusive coding education

[Justin Obara]

At this week’s Community Meeting 

 ( Nov 29, 2022 ) Maysa Borges Gama will be speaking about her work on 
Human-robot interaction for inclusive coding education.

Description:

Educational Robotics is a widely researched and applied field, but most 
robotics courses for children and young are not designed or adapted for 
learners with disability. This context is even less explored when we observe 
the use of social robots for education since most human-robot interactions 
designed for people with disability are focused in rehabilitation, mobility, or 
diagnosis. Robots, especially social robots, can act as powerful tools for 
teaching coding to school-aged children with special needs. In this meeting, I 
am going to present a status report on my master's course project that seeks to 
adapt the Weavly  platform experience into a human-robot 
interaction.

Time:
2:00 - 3:00pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Oct 12 ): UofT MScAC Applied Research Collaborations

[Justin Obara]

At this week’s Community Meeting 

 ( Oct 12, 2022 ) Daniel Giovannini (Associate Director, MScAC Partnerships at 
U of T), will be joining to learn more about the recent work at the IDRC, and 
explore whether there may be opportunities for MScAC graduate students to work 
on collaborative research projects involving the IDRC and/or any of our 
partners.

Description:

MScAC (Master of Science in Applied Computing) 
 is a world-class 
professional graduate program that provides a broad range of industry and 
community partners with direct access to applied research talent: in addition 
to the same graduate-level technical courses as our MSc program, MScAC also 
involves each MScAC graduate student in an 8-month applied research internship 
in the last part of the program.

I would be interested to learn more about the recent work in your research 
group, and to explore whether there may be opportunities for some of our 
students to complement your team at the IDRC in collaborative research work you 
may be conducting in partnership with industry and community partners.

2023 MScAC partner handbook 

Brochures for the annual Applied Research in Action showcase 


Time:
2:30 - 4:00pm ET

Location:
Locally: IDRC Office 
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( July 5 ) - CTA Image inspection

[Justin Obara]

There will be a Community Design Crit on July 5, 2022, 2pm to 3pm ET.

Topic: CTA Image inspection

Description:
The Canadian Typography Archives website requires an image inspection function 
that allows a user to magnify an artifact and pan over all parts of the 
artifact. 
Here is a link 

 to an example of image inspection we are seeing as an exemplar experience 
using mouse functionality 
The CTA team has had some discussion and noted the following:
• WCAG 2.1 (note AODA references WCAG 2.0)
• 2.1.1 keyboard 
; 4.1.2 name role 
value 
• 2.5.1 path based and multi point gesture 
 (this may 
apply)
• What to do:
• Provide controls that perform same behaviour as the mouse
• When image opens buttons appear and are in the focus order
• Mobile: pinching, alternative is zoom in zoom out and button controls 
as well.
• concern: Buttons for keyboard manoeuvre may not be a smooth experience
We look forward to the discussion!

Links:
Example image 

WCAG 2.1: Understanding Success Criterion
2.1.1 keyboard 
4.1.2 name role value 

2.5.1 path based and multi point gesture 


Facilitator: Caren Watkins

Meeting Details:

Date: July 5, 2022
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( May 24 ): Meeting with Jack Tyrrell from the Centre for Inclusive Design

[Justin Obara]

At next week’s Community Meeting 

 ( May 24, 2022 ) Jack Tyrrell from the Centre for Inclusive Design 
 will be joining us to present on his 
work.

Time:
2:00 - 3:00pm ET

Location:
Locally: IDRC Office  (OCAD’s 
COVID policies must be followed to attend in person. Please contact me if you 
have questions).
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

CANCELLED - Re: Community Design Crit ( May 19, 2022 ) - IDRC Website Projects Page(s) - CANCELLED

[Justin Obara]

Sorry some scheduling conflicts have arisen for this Design Crit and it will 
need to be cancelled.

Sorry for the inconvenience.
Justin

> On May 17, 2022, at 9:17 AM, Justin Obara  wrote:
> 
> There will be a Community Design Crit on May 19, 9am to 10am ET.
> 
> Topic: IDRC Website Projects Page(s)
> 
> Description:
> 
> We’ll discuss the Project page(s) <https://idrc.ocadu.ca/projects-and-tools/> 
> on the IDRC site. We plan to discuss what the original plans were and how the 
> site, as it currently is, is meeting current needs/requirements.
> 
> Links:
> Task board <https://github.com/inclusive-design/idrc/projects/2> for the IDRC 
> site redesign
> Project page(s) <https://idrc.ocadu.ca/projects-and-tools/>
> 
> Meeting Details:
> 
> Date: May 19, 2022
> Time: 9am to 10am ET
> Virtual Meeting : zoom 
> <https://ocadu.zoom.us/j/727986784?pwd=dFp2a1dybkEyUHFSa0NyOU4wVk94Zz09>
> 
> Other Information:
> 
> Please visit the Inclusive Design Critiques and Workshops 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  wiki page, for more information including the schedule of upcoming events. 
> 
> Contributions are licensed under Creative Commons Attribution 4.0 
> International License <https://creativecommons.org/licenses/by/4.0/> and 
> follow the Fluid and Inclusive Design Community Code of Conduct 
> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>  (Note: some demonstrated/presented or discussed software, hardware, 
> research, tools and etc, may have their own license.)
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( May 19, 2022 ) - IDRC Website Projects Page(s)

[Justin Obara]

There will be a Community Design Crit on May 19, 9am to 10am ET.

Topic: IDRC Website Projects Page(s)

Description:

We’ll discuss the Project page(s)  
on the IDRC site. We plan to discuss what the original plans were and how the 
site, as it currently is, is meeting current needs/requirements.

Links:
Task board  for the IDRC 
site redesign
Project page(s) 

Meeting Details:

Date: May 19, 2022
Time: 9am to 10am ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Design Crit ( April 28, 2022 ) - IDRC Site Projects Page - POSTPONED

[Justin Obara]

Due to scheduling issues we’ll need to reschedule this meeting for a later 
time. Sorry for any inconvenience this may have caused.

Thanks
Justin

> On Apr 25, 2022, at 8:10 AM, Justin Obara  wrote:
> 
> There will be a Community Design Crit on April 28, 10 to 11am ET.
> 
> Topic: IDRC Site Projects Page
> 
> Description:
> 
> We’ll discuss the Project page(s) <https://idrc.ocadu.ca/projects-and-tools/> 
> on the IDRC site. We plan to discuss what the original plans were and how the 
> site, as it currently is, is meeting current needs/requirements.
> 
> Links:
> Task board <https://github.com/inclusive-design/idrc/projects/2> for the IDRC 
> site redesign
> 
> Facilitator: Name
> 
> Meeting Details:
> 
> Date: April 28, 2022
> Time: 10 - 11am ET
> Virtual Meeting : zoom 
> <https://ocadu.zoom.us/j/727986784?pwd=dFp2a1dybkEyUHFSa0NyOU4wVk94Zz09>
> 
> Other Information:
> 
> Please visit the Inclusive Design Critiques and Workshops 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  wiki page, for more information including the schedule of upcoming events. 
> 
> Contributions are licensed under Creative Commons Attribution 4.0 
> International License <https://creativecommons.org/licenses/by/4.0/> and 
> follow the Fluid and Inclusive Design Community Code of Conduct 
> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>  (Note: some demonstrated/presented or discussed software, hardware, 
> research, tools and etc, may have their own license.)
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( April 28, 2022 ) - IDRC Site Projects Page

[Justin Obara]

There will be a Community Design Crit on April 28, 10 to 11am ET.

Topic: IDRC Site Projects Page

Description:

We’ll discuss the Project page(s)  
on the IDRC site. We plan to discuss what the original plans were and how the 
site, as it currently is, is meeting current needs/requirements.

Links:
Task board  for the IDRC 
site redesign

Facilitator: Name

Meeting Details:

Date: April 28, 2022
Time: 10 - 11am ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Infusion 4.0 released

[Justin Obara]

The Fluid community is pleased to announce the release of Infusion 4.0!

Infusion 4.0 includes many changes to the core and preferences framework and 
may not be backwards compatible with previous versions of Infusion.

Please see:

API Changes from 3.0 to 4.0 

Deprecated in 4.0 

Issues addressed in 4.0.0 

Changes in 4.0.0 

Release Notes 
 
Highlights in Infusion 4 include:

Changes to the Preferences Framework to make it easier to integrate in terms of 
choosing which preferences are used and working with styling enactors via CSS 
custom properties
Improvements to localization of the Preferences Framework/UI Options, and 
resource loaders
The foundation of the Potentia II work and future framework 
changes/improvements.

See: CHANGELOG.md 

 for more details.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Feb 8, 2022 ) - Dobble Debate - Bake Your Own

[Justin Obara]

There will be a Community Design Crit on Feb 8, 2022, 2pm to 3pm ET.

Topic: Dobble Debate - Bake Your Own

Description:

A continuation of the Design Crit from January 18, 2022, focused on the Bake 
Your Own experience.

Dobble Debate: debating with a difference, is a game that facilitates 
discussions and learning about human difference. The game employs the powers of 
play and humor to catalyze open discussion and compassionate thinking around 
topics that are often considered taboo. Players are challenged to rethink 
assumptions they may have around what it means to be disabled or have lived 
different experiences from their own.

Dobble Debate recognizes that every individual’s lived experience is different, 
and changes significantly based on their current environment. Therefore, we 
explicitly acknowledge D/deafness, disability, differing abilities , autism, 
and neurodiversity plus (DDDAND+). This acronym does not cover all the diverse 
identities usually lumped under ‘disability’; we are using it to draw attention 
to the variety of human experience. The label of ‘disability’ runs the risk of 
minimizing the diversity of lived differences.

Links:
Dobble Debate 

Facilitator: Name

Meeting Details:

Date: Feb 22, 2022
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Meeting ( Jan 25 ): An artifact to aid the design of 3D printed audio-tactile graphics for blind students: a Ph.D. research

[Justin Obara]

Hi Tony,

Here are the resources (Video Recording 
<https://idrc.cachefly.net/wiki.fluidproject.org/videos/IDRC_CommunityWorkshop_audio-tactileGraphics_2022-01-25.mp4>,
 Presentation 
<https://docs.google.com/presentation/d/1SQ1zPpT-n_9Yhe25GYIAtLQhZp3Ei36LrxPLzoCgWoA/edit#slide=id.p>,
 and Miro Board <https://miro.com/app/board/uXjVOSj9Ayk=/>) from the community 
meeting. They’ve also been linked to from the Community workshops and design 
crits 
<https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
 wiki page. I’ve fixed a broken link to the Presentation on the wiki page as 
well.

Thanks
Justin

> On Jan 28, 2022, at 12:32 PM, Tony Atkins  wrote:
> 
> Hi, Justin.
> 
> I get an error when trying to open the attachment.
> 
> Also, was there a recording of the presentation made?
> 
> 
> T
> 
> On Mon, 24 Jan 2022 at 14:17, Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> At this week’s Community Meeting 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  ( Jan 25, 2022 ), Emilia Christie Picelli Sanches will be speaking about her 
> work on an artifact to aid the design of 3D printed audio-tactile graphics 
> for blind students.
> 
> Presentation 
> <https://can01.safelinks.protection.outlook.com/?url=https://docs.google.com/presentation/d/1SQ1zPpT-n_9Yhe25GYIAtLQhZp3Ei36LrxPLzoCgWoA/edit?usp=sharing&data=04%7c01%7cjob...@ocadu.ca%7C60bc10524a2345b43c2c08d9d4547492%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637774281468151379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=%7C3000&sdata=R+K8w2bQE7iNWChDnTXM3cAA1kJMaV1RPgtN/hTCor0=&reserved=0>
> 
> Description:
> 
> Emilia Sanches is a Ph.D. candidate who's coming to IDRC to develop part of 
> her research. This community workshop intends to contextualize her research 
> and her preliminary results. She'll briefly introduce what are 3D printed 
> audio-tactile graphics and proceed to talk about what she is doing and what 
> her next steps are. People are encouraged to ask questions and discuss the 
> topic.
> 
> Time:
> 2:00 - 3:00pm ET
> 
> Location:
> Remotely: Zoom 
> <https://ocadu.zoom.us/j/727986784?pwd=dFp2a1dybkEyUHFSa0NyOU4wVk94Zz09>
> 
> 
> Please visit the Inclusive Design Critiques and Workshops 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  wiki page, for more information including the schedule of upcoming events. 
> 
> Contributions are licensed under Creative Commons Attribution 4.0 
> International License <https://creativecommons.org/licenses/by/4.0/> and 
> follow the Fluid and Inclusive Design Community Code of Conduct 
> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>  (Note: some demonstrated/presented or discussed software, hardware, 
> research, tools and etc, may have their own license.)
> 
> Thanks
> Justin
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> <mailto:fluid-work@lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Jan 25 ): An artifact to aid the design of 3D printed audio-tactile graphics for blind students: a Ph.D. research

[Justin Obara]

At this week’s Community Meeting 

 ( Jan 25, 2022 ), Emilia Christie Picelli Sanches will be speaking about her 
work on an artifact to aid the design of 3D printed audio-tactile graphics for 
blind students.

Presentation 


Description:

Emilia Sanches is a Ph.D. candidate who's coming to IDRC to develop part of her 
research. This community workshop intends to contextualize her research and her 
preliminary results. She'll briefly introduce what are 3D printed audio-tactile 
graphics and proceed to talk about what she is doing and what her next steps 
are. People are encouraged to ask questions and discuss the topic.

Time:
2:00 - 3:00pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: ILDH design update - repo?

[Justin Obara]

I suppose there’s another option. I’m not sure how much work this would be or 
other issues, so it may not be worthwhile.

We could unarchive the original repo, and archive the current one. There by 
renaming nothing. You could look into merging the two repos as well, if you 
wanted to preserve the history across the two.

Some drawbacks would be:

Need to move issues from current repo to the former one (GitHub has a mechanism 
for this)
Would need to merge the repos if you want all the history in one place
If repos aren’t merged, there would be some work to copy/port over existing 
codebase from current repo

If this approach isn’t taken, I’m fine with Option 1. However we need to 
indicate somewhere in the current repo a reference to the original repo. All in 
all, I’m glad we’re fixing this up as I’ve had issues locating the repo for 
this site on a few occasions.

Thanks
Justin


> On Jan 18, 2022, at 9:26 AM, Michelle D'Souza  wrote:
> 
> I like option 1 - it’s a lot clearer for folks coming to the repo later or 
> after a long break. 
> 
> Thanks,
> 
> Michelle
> 
> 
> 
>> On Jan 17, 2022, at 6:53 PM, Gregor Moss > > wrote:
>> 
>> Hello! I hope everyone is keeping well and had a pleasant holiday season.
>>  
>> In the very near future, we’ll begin reworking the Inclusive Learning Design 
>> Handbook (ILDH) to incorporate a new design, and it would be great to get 
>> your input on a question related to repository naming.
>>  
>> Context:
>> URL: https://handbook.floeproject.org/ 
>> Current repo: docs-inclusive-learning 
>>  – 11ty, 
>> previously DocPad (active since 2015)
>> Archived repo: handbook.floeproject.org 
>>  – MediaWiki 
>> (active 2011-2015)
>>  
>> The upcoming work will build upon the current codebase, which I thought 
>> would be a good opportunity to rename the repo given the site’s name and 
>> URL. The name of the archived repo seems the most appropriate in my opinion, 
>> though alternatives such as “ildh” or “inclusive-learning-design-handbook” 
>> would be serviceable.
>>  
>> Which of these options would you choose, and why? Or, would you choose 
>> another option?
>> Rename the archived repo and rename the current repo to take the former’s 
>> name
>> Rename the current repo a new and less ambiguous name
>> Do nothing – leave the names as they are
>>  
>> It’s worth noting that redirects to a previous name are preserved by GitHub 
>> according to their documentation 
>> ,
>>  EXCEPT if the name is reused. So Option 1 would break any redirects to the 
>> old repo (redirects which are over 6 years stale at this point, 
>> potentially), and Option 2 would preserve any redirects to the current repo.
>>  
>> Cheers,
>> Gregor
>> ___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> 
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Jan 18, 2022 ) - Dobble Debate

[Justin Obara]

There will be a Community Design Crit on Jan 18, 2022, 2pm to 3pm ET.

Topic: Dobble Debate

Description:

Dobble Debate: debating with a difference, is a game that facilitates 
discussions and learning about human difference. The game employs the powers of 
play and humor to catalyze open discussion and compassionate thinking around 
topics that are often considered taboo. Players are challenged to rethink 
assumptions they may have around what it means to be disabled or have lived 
different experiences from their own.

Dobble Debate recognizes that every individual’s lived experience is different, 
and changes significantly based on their current environment. Therefore, we 
explicitly acknowledge D/deafness, disability, differing abilities , autism, 
and neurodiversity plus (DDDAND+). This acronym does not cover all the diverse 
identities usually lumped under ‘disability’; we are using it to draw attention 
to the variety of human experience. The label of ‘disability’ runs the risk of 
minimizing the diversity of lived differences.

Links:
Dobble Debate 

Facilitator: Lynne Heller

Meeting Details:

Date: Jan 18, 2022
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Meeting/Design Crit ( Nov 16 ): Participatory Design of the CareBank, a Mobile Telecare Platform for Interpersonal Empowerment through Peer-to-Peer Circles of Care

[Justin Obara]

If you missed today’s community meeting/Design Crit, a video recording 
<https://idrc.cachefly.net/wiki.fluidproject.org/videos/IDRC_CommunityWorkshop_CareBank_2021-11-16.mp4>
 is available. Also, if you’re interested in contributing to the project, you 
can find the code at https://github.com/CAGoodman/CareWheelsCorp 
<https://github.com/CAGoodman/CareWheelsCorp>

Thanks
Justin

> On Nov 11, 2021, at 3:49 PM, Justin Obara  wrote:
> 
> At the upcoming  
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>Community
>  Meeting 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>/Design
>  Crit ( Nov 16, 2021 ) Claude Goodman will be leading a discussion and Crit 
> about the CareBank.
> 
> Description:
> 
> The CareWheels Living Lab demonstrated the value of engaging people living 
> independently with severe disabilities to design
> the CareBank, a peer-to-peer Telecare platform for their mutual benefit. 
> Together we learned which Internet of Things (IoT) technologies worked well, 
> and more meaningfully, we learned how to design Mobile and IoT technologies 
> to help people work well together. Please join us for a Community Meeting 
> presentation about the CareBank Platform and Design Crit about the CareBank 
> App. The CareBank Project won a National Academy of Medicine Healthy 
> Longevity Innovation Catalyst Award 
> <https://healthylongevitychallenge.org/winners/carebank-a-peercare-platform-connecting-elders-for-the-pandemic-and-aftermath/>.
> 
> Time:
> 2:00 - 3:30pm ET
> 
> Location:
> Remotely: Zoom 
> <https://ocadu.zoom.us/j/727986784?pwd=dFp2a1dybkEyUHFSa0NyOU4wVk94Zz09>
> 
> 
> Please visit the Inclusive Design Critiques and Workshops 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
>  wiki page, for more information including the schedule of upcoming events. 
> 
> Contributions are licensed under Creative Commons Attribution 4.0 
> International License <https://creativecommons.org/licenses/by/4.0/> and 
> follow the Fluid and Inclusive Design Community Code of Conduct 
> <https://wiki.fluidproject.org/display/fluid/Inclusion+in+the+Fluid+Community>.
>  (Note: some demonstrated/presented or discussed software, hardware, 
> research, tools and etc, may have their own license.)
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

New designs for UI Options (UIO)

[Justin Obara]

Hi everyone,

Uttara has been working on updated designs for UI Options (UIO). We’re hoping 
to have a Design Crit later this year or the beginning or next. These are still 
a work in progress, but please let us know your thoughts and if you have any 
suggestions or comments. 

UIO 2.0 designs on the wiki 
Figma 

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting/Design Crit ( Nov 16 ): Participatory Design of the CareBank, a Mobile Telecare Platform for Interpersonal Empowerment through Peer-to-Peer Circles of Care

[Justin Obara]

At the upcoming Community Meeting/Design Crit 
Community
 Meeting 
/Design
 Crit ( Nov 16, 2021 ) Claude Goodman will be leading a discussion and Crit 
about the CareBank.

Description:

The CareWheels Living Lab demonstrated the value of engaging people living 
independently with severe disabilities to design
the CareBank, a peer-to-peer Telecare platform for their mutual benefit. 
Together we learned which Internet of Things (IoT) technologies worked well, 
and more meaningfully, we learned how to design Mobile and IoT technologies to 
help people work well together. Please join us for a Community Meeting 
presentation about the CareBank Platform and Design Crit about the CareBank 
App. The CareBank Project won a National Academy of Medicine Healthy Longevity 
Innovation Catalyst Award 
.

Time:
2:00 - 3:30pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Code Freeze for Infusion 3.0

[Justin Obara]

Now that Infusion 3.0 has been released and we’ve updated the repo to be ready 
for Infusion 4.0 work, the repository is officially unfrozen.

Thanks
Justin

> On Jun 24, 2021, at 1:02 PM, Justin Obara  wrote:
> 
> We’re beginning the process of publishing an Infusion 3.0 release. We have 
> been putting out many dev releases as we’ve been working towards an Infusion 
> 3.0 release; which many have already been using in their projects. We’ve 
> recently split off a portion of that work to be part of a future Infusion 4.0 
> release ( https://github.com/fluid-project/infusion/pull/1052 
> <https://github.com/fluid-project/infusion/pull/1052> ). 
> 
> At this point we’re ready to start the process of testing what is in main, 
> with the hope of putting out an Infusion 3.0 release shortly. Please consider 
> the main branch of the Infusion repo 
> <https://github.com/fluid-project/infusion> to be frozen, until a release is 
> cut.  Only changes related to any potential blockers, and release tasks will 
> be accepted for merging.
> 
> If you have some spare cycles, please do help with the testing tasks 
> <https://docs.google.com/document/d/17plySmtiLvcoUUegAe1Hajcoo3rzkCWi7kLGXhbXyW4/edit#heading=h.yptafwv26iyl>.
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Infusion 3.0 released

[Justin Obara]

The Fluid community is pleased to announce the release of Infusion 3.0!

Infusion 3.0 includes many changes to the core and preferences framework and 
may not be backwards compatible with previous versions of Infusion. All bundled 
JS files are now minified, so you may need to updated your imports if you were 
specifically requesting minified versions for previous releases. 

Please see API Changes from 2.0 to 3.0 
 and 
Deprecations in 3.0 
 on the 
Infusion Documentation  
site. 

Release Notes 


What's New in 3.0.0?

Build
Minified distributions:
infusion-all.js
infusion-all-no-jquery.js
infusion-framework.js
infusion-framework-no-jquery.js
infusion-uio.js
infusion-uio-no-jquery.js
Framework
Added model transformations for converting between:
Boolean values and Strings
fluid.transforms.booleanToString
fluid.transforms.stringToBoolean
Date/Time and Strings
fluid.transforms.dateToString
fluid.transforms.dateTimeToString
fluid.transforms.stringToDate
JSON Objects and Strings
fluid.transforms.objectToJSONString
fluid.transforms.JSONstringToObject
Updated model transformations:
Number to String transformation supports specifying decimal precision.
Round transformation can round to an integer or decimal value
fluid.stringTemplate updated to support nested objects for interpolating values
Added fluid.dataSource grade
Added fluid.remoteModelComponent for keeping remote and local models in sync.
Preference framework
Switched from Stylus to SASS for CSS pre-processing
Responsive design for small screens/mobile devices.
Updated look of on/off toggles and checkboxes
Added additional contrast themes based on Windows contrast themes.
Added the OpenDyslexic 3  font as an option to the 
Text Style panel
Added localized message bundles for Farsi, French, Portuguese, and Spanish.
New preferences:
Letter spacing
Syllabification preference
Text-to-speech preference using the Orator component
Word spacing preference
Orator
A self voicing widget with play/pause, text highlighting, selection reading.
NOTE: Currently there is a bug with Google supplied voice synthesizers that 
prevents text highlighting and long text being synthesized in Chrome. See 
FLUID-6635 
Test Infrastructure
jqUnit.test supports async tests with promises

Deprecated

More information about deprecations can be found in the Deprecated in 3.0 docs 
.

Fast XML Pull
Will be removed in a future release.
Pager
fluid.pagedTable and fluid.table grades and related functionality will be 
removed in an upcoming release.
Renderer
The Renderer will be completely overhauled in an upcoming release. Expect API 
breakage, and that all of the existing Renderer implementation is deprecated. 
This includes potential API breakages for the Preferences Framework and 
Infusion components that use the Renderer.

Obtaining Infusion

Fork on GitHub 
Download a Build 
Install from NPM 

A lot of time and effort has gone into this release, and we’d like to thank 
everyone in the community for their contributions.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( August 17 ): Using LiveCode to go from prototype to app

[Justin Obara]

At the upcoming Community Meeting 

 ( August 17, 2021 ), Martin Koob will be talking about LiveCode.

Description:

This will be an interactive, hands on workshop where you will learn how to use 
LiveCode , an open source IDE,  to prototype an 
interface, add code to the interface components and build an app that you could 
deploy on multiple platforms. Be ready to try a different paradigm using an 
easy to understand English like language and an IDE that lets you run your 
prototype/app as you build it. Download the IDE 
 before the workshop if you want 
to follow along on your own Mac, Windows or Linux machine.

Time:
2:00 - 3:30pm ET

Location:
Remotely: Zoom 



Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Tuesday August 3, 2021 ) - Canadian Typography Archives Part 2

[Justin Obara]

There will be a Community Design Crit on Tuesday August 3, 2021, 2pm to 3pm ET.

Topic: Canadian Typography Archives Part 2

Description:
The goal of the Canadian Typography Archives (CTA) is to create a free and open 
dedicated online space for documenting the histories of type and typography in 
Canada, whether currently public, privately held, still to be discovered, or 
not yet acknowledged or represented. To begin with the site will focus on 
pre-digital histories (approximately before 1985). 

On July 27th, we presented mid-fidelity wireframes of the CTA header and footer 
and received good feedback on ways to improve the functionality to meet 
accessibility guidelines. Figma File 

 from the session

As an extension of the session, we are looking to center the discussion around 
the individual artifact (content) pages and get feedback on various elements 
within the layout in regards to different interaction states, content layout 
and overall functionality.

Links:
Figma Prototype 


Facilitator: Kala and Caren

Meeting Details:

Date: Tuesday August 3, 2021
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Tuesday July 20, 2021 ) - Follow up on: Sonification for Balloons and Static Electricity PhET sim

[Justin Obara]

There will be a Community Design Crit on Tuesday July 20, 2021, 2pm to 3pm ET.

Topic: Follow up on: Sonification for Balloons and Static Electricity PhET sim

Description:
During our work on Balloons and Static Electricity we ended up creating an 
audio tool to help us iterate on what wounded and worked best. I’ll update 
everyone on the progress since the last Design Crit and discuss the 
difficulties we had and the decisions we made during the process. 

Links:
Demo 

Click on the PhET logo at the bottom left and then “Options” from that popup. 
This will allow you to use the audio tool to adjust the sound of the 
interaction between the charged balloon and the wall.

Facilitator: Ashton Morris

Meeting Details:

Date: Tuesday July 20, 2021
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Design Crit ( Tuesday July 13, 2021 ) - VideoLinkwell, streamlining the workflow in an interactive video eLearning app

[Justin Obara]

There will be a Community Design Crit on Tuesday July 13, 2021, 2pm to 3pm ET.

Topic: VideoLinkwell, streamlining the workflow in an interactive video 
eLearning app

Description:
Martin Koob will demo his SaaS application VideoLinkwell. It is used in Sign 
Language interpreter training to record a learner's interpretation of a video 
sample and then allow teachers to give  feedback by annotating the resulting 
video at various time points in the video with video or text comments. The goal 
is to facilitate and streamline the process of providing feedback in Sign 
Language. He is looking for feedback on the UX and workflow for teachers and 
and learners in creating, sharing, assessing and reviewing their projects. For 
more information on the application see VideoLinkwell.com 


Links:
VideoLinkwell.com 

Facilitator: Martin Koob

Meeting Details:

Date: Tuesday July 13, 2021
Time: 2pm to 3pm ET
Virtual Meeting : zoom 


Other Information:

Please visit the Inclusive Design Critiques and Workshops 

 wiki page, for more information including the schedule of upcoming events. 

Contributions are licensed under Creative Commons Attribution 4.0 International 
License  and follow the Fluid and 
Inclusive Design Community Code of Conduct 
. 
(Note: some demonstrated/presented or discussed software, hardware, research, 
tools and etc, may have their own license.)

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( June 29 @ 12:30pm ET ): Garages, Builders, and Games

[Justin Obara]

At this week’s Community Meeting 

 ( 29 June 2021 ) Tony will be talking about Game Builder Garage 
.

Description:
Recently, Nintendo released Game Builder Garage, an environment in which the 
goal is to build, play, and share games.  This talk will highlight a few things 
about Game Builder Garage as a programming, learning, and playful environment.

Time:
12:30 - 1:30pm ET

Location:
Remotely: Zoom 


Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Code Freeze for Infusion 3.0

[Justin Obara]

We’re beginning the process of publishing an Infusion 3.0 release. We have been 
putting out many dev releases as we’ve been working towards an Infusion 3.0 
release; which many have already been using in their projects. We’ve recently 
split off a portion of that work to be part of a future Infusion 4.0 release ( 
https://github.com/fluid-project/infusion/pull/1052 
 ). 

At this point we’re ready to start the process of testing what is in main, with 
the hope of putting out an Infusion 3.0 release shortly. Please consider the 
main branch of the Infusion repo  to 
be frozen, until a release is cut.  Only changes related to any potential 
blockers, and release tasks will be accepted for merging.

If you have some spare cycles, please do help with the testing tasks 
.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Collecting CLAs for contributions made outside of GitHub

[Justin Obara]

Hi Gio,

I don’t think there is a web flow, but we could look at other ways of 
performing the signature with CLA Assistant lite. In the boilerplate GA 
workflow file  
<https://github.com/cla-assistant/github-action#1-add-the-following-workflow-file-to-your-repository-in-this-pathgithubworkflowsclayml>that
 they provide there is a condition that checks comments for “recheck”, the 
signature, or PR event. We might be able to add some other event signing the 
CLA or add some other functionality to have some web flow write a comment with 
the appropriate signature. Would have to investigate in more detail though, but 
at least there are things we could explore.

Thanks
Justin

> On May 3, 2021, at 9:47 AM, Giovanni Tirloni  wrote:
> 
> Is there a web flow for new CLA signatures that could be used for new users 
> (in Netlify CMS, another app, or an explicit request)? Or is it only through 
> PR comments (that users get to know where to go)?
> 
> 
> From: fluid-work  on behalf of Justin 
> Obara 
> Sent: Monday, May 3, 2021 10:43
> To: fluid-work@lists.idrc.ocad.ca 
> Subject: Collecting CLAs for contributions made outside of GitHub
>  
> Hi Everyone,
> 
> It’s been a wile since we switched from our paper/pdf based CLAs to using CLA 
> Assistant 
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcla-assistant.io%2F&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943368033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fIAC4m9Pg5kERe2wiDckkB%2FPR4YpKA1gJbm9YI%2B1Wfs%3D&reserved=0>
>  to require digital signatures when submitting PRs to our GitHub repos. 
> However, we’ve found that this workflow doesn’t work well when contributions 
> are made through an external means, such as Netlify CMS 
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.netlifycms.org%2F&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943378022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ItGPxp9e1dNjNKh%2FBvp3gkmslxwAO2g5ahm%2BhWpK38E%3D&reserved=0>.
>  In such a case the contribution is made in the external system and submitted 
> as a commit to GitHub in a Pull Request. But the contributor may not have a 
> GitHub account and doesn’t really ever need to see the GitHub UI to make the 
> contribution. This means that they have no means of accepting the CLA.
> 
> Typically we only required the CLA be signed for code contributions, so for 
> now, things like Netlify CMS contributions would likely fall outside of that 
> requirement. Unfortunately, CLA Assistant doesn’t allow much breadth in terms 
> of customization options. We can add users to an allowlist, exclude some 
> repos, or have a minimum number of line or file changes. However, none of 
> those options fully satisfy the case. For example, ideally we’d still require 
> a CLA to be signed for code changes.
> 
> Another option would be to transition to using CLA assistant lite 
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmarketplace%2Factions%2Fcla-assistant-lite&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943378022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zs9WiCRjDdgB1gP1OuKrbn4PGMlSXtINX%2FzelV6PB%2Fc%3D&reserved=0>,
>  which is a GitHub Action variant of CLA Assistant. Some benefits:
> 
> Anyone could configure
> right now only I can configure CLA Assistant
> More configuration options available as we have more control over 
> configuration for Github Actions. 
> E.g. running against specific branches and etc.
> Although configuration is still limited
> Would be easier to have different configurations for each repo
> 
> Some drawbacks:
> 
> More work for configuring/setting up. 
> At the moment CLA Assistant is configured per org, so all repos share the 
> same configuration. CLA Assistant is configured per repo. 
> May be able to mitigate the work for new repos by creating a template repo, 
> but would have to update all existing repos.
> 
> Additionally we’d need to decide where to store the signatures. They could 
> either be committed into a file in the repo, or stored in an external repo, 
> which would allow us to centralize the signatures and could even be private 
> if desired.
> 
> There are additional options though. 
> Switch to a Developer Certificate of Origin (DCO),
> may not help with Netlify CMS issue
> Info on CLA v

Collecting CLAs for contributions made outside of GitHub

[Justin Obara]

Hi Everyone,

It’s been a wile since we switched from our paper/pdf based CLAs to using CLA 
Assistant  to require digital signatures when 
submitting PRs to our GitHub repos. However, we’ve found that this workflow 
doesn’t work well when contributions are made through an external means, such 
as Netlify CMS . In such a case the contribution 
is made in the external system and submitted as a commit to GitHub in a Pull 
Request. But the contributor may not have a GitHub account and doesn’t really 
ever need to see the GitHub UI to make the contribution. This means that they 
have no means of accepting the CLA.

Typically we only required the CLA be signed for code contributions, so for 
now, things like Netlify CMS contributions would likely fall outside of that 
requirement. Unfortunately, CLA Assistant doesn’t allow much breadth in terms 
of customization options. We can add users to an allowlist, exclude some repos, 
or have a minimum number of line or file changes. However, none of those 
options fully satisfy the case. For example, ideally we’d still require a CLA 
to be signed for code changes.

Another option would be to transition to using CLA assistant lite 
, which is a GitHub 
Action variant of CLA Assistant. Some benefits:

Anyone could configure
right now only I can configure CLA Assistant
More configuration options available as we have more control over configuration 
for Github Actions. 
E.g. running against specific branches and etc.
Although configuration is still limited
Would be easier to have different configurations for each repo

Some drawbacks:

More work for configuring/setting up. 
At the moment CLA Assistant is configured per org, so all repos share the same 
configuration. CLA Assistant is configured per repo. 
May be able to mitigate the work for new repos by creating a template repo, but 
would have to update all existing repos.

Additionally we’d need to decide where to store the signatures. They could 
either be committed into a file in the repo, or stored in an external repo, 
which would allow us to centralize the signatures and could even be private if 
desired.

There are additional options though. 
Switch to a Developer Certificate of Origin (DCO),
may not help with Netlify CMS issue
Info on CLA vs DCO 

Drop the CLA requirement completely
Keep CLA Assistant as is, and exclude some repos; moving them to CLA Assistant 
lite or something else.
etc.

Another conversation that may be needed, along with this or separate, is how we 
inform contributors using external systems like Netlify CMS and etc. about what 
the contributor license is (e.g. CC BY 4.0), privacy policy, code of conduct 
and etc. 

It would be great to hear what the community thinks about this and what 
suggestions you all may have.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Mar 2 ): Artifact Ecologies

[Justin Obara]

At this week’s Community Meeting 

 ( Mar 2, 2021 ) Philip Tchernavskij will be speaking to us about artifact 
ecologies.


Time:
2:00 - 3:30pm ET

Location:
Remotely: Zoom 


Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Jan 26 @ 2pm ET ): A research on 3D printed audio-tactile graphics

[Justin Obara]

At this week’s Community Meeting 

 ( Jan 26, 2021 ) Emilia Sanches will be talk about "A research on 3D printed 
audio-tactile graphics”. 

Slides 


Time:
2:00 - 3:30pm ET

Location:
Remotely: Zoom 


Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re:

[Justin Obara]

Hello Allen,

Thank you for our interest in our organization. Could you tell us what has made 
you interested in contributing to our organization? Have you reviewed our work, 
is there are particular area you would like to contribute to?

If you have come here by way of GSoC, we may not be participating this year. 

Thanks
Justin

> On Jan 13, 2021, at 5:30 AM, Allen Y  wrote:
> 
>   Hi ,my name is  Allen.Y. I am a 2nd-year B.Tech student in CSE at College 
> Of Engineering,Trivandrum,Kerala,India
>  I have keen interest in coding and in contributing to open source.I 
> know programminglanguages like C,Java , Python, Javascript, HTML5 ,CSS, 
> React, Django, Node, Kotlin.I have   been designing web pages from the very 
> beginning of my college year. I have worked as a web development intern at 
> Admere Selvyn Private Limited ,Jharkhand,India
> I am familiar with all the technologies mentioned in your organisation. I 
> have read through all the guidelines and I have become very much interested 
> in contributing to your organisation.What are the initial steps that I should 
> follow i.e from where to start contributing and the procedures that are to be 
> familiarised for start contributing. I am very much excited
> and interested in contributing  to your organisation.
>  Thank you in advance.
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Fwd: IDRC/Fluid websites: migration timeline

[Justin Obara]

Please see below for site migrations that may briefly affect your work as sites 
are moved. In particular Friday Feb 22 and Saturday 23, when the wiki and JIRA 
will be migrated.

Thanks
Justin

> Begin forwarded message:
> 
> From: Giovanni Tirloni 
> Subject: IDRC/Fluid websites: migration timeline
> Date: January 11, 2021 at 12:23:22 PM EST
> To: "every...@lists.idrc.ocad.ca" 
> 
> Hello,
> 
> We are at a point where our new infrastructure running on Amazon AWS is 
> getting ready to start receiving migrations.
> 
> After getting feedback on Matrix about the proposed timeline, I came up with 
> the following schedule and would appreciate any feedback on it.
> 
> Migration work would start at 5am Eastern and stop at most at 9am Eastern 
> each day:
> 
> Jan 18 - Monday:
> bigidea.one
> canhack150.ca 
> deep-dev.idrc.ocadu.ca 
> deep.idrc.ocadu.ca 
> dev.bigidea.one
> 
> Feb 19 - Tuesday:
> hackathon.inclusivedesign.ca 
> inclusivedesign.ca 
> opendoors.idrc.ocadu.ca 
> 
> Feb 20 - Wednesday:
> snow-dev2.idrc.ocadu.ca 
> snow.idrc.ocadu.ca 
> wecount-cms.inclusivedesign.ca   
> wecount-dev.inclusivedesign.ca 
> Feb 21 - Thursday:
> analytics.inclusivedesign.ca 
> 
> Feb 22 - Friday:
> wiki.fluidproject.org  (Fluid)
> 
> Feb 23 - Saturday:
> issues.fluidproject.org  (Fluid)
> 
> Feb 25 - Monday:
> timetrack.idrc.ocadu.ca  (Iris)
> achecker.ca  (Cindy)
> 
> Please reply with any feedback you might have.
> 
> Thank you,
> Giovanni Tirloni
> DevOps Engineer
> Inclusive Design Research Centre, OCAD University
> https://idrc.ocadu.ca 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re:

[Justin Obara]

Hello Amulya,

Thanks for your interest in our work and for introducing yourself. 

To start we do not yet know if we will be participating in GSoC 2021, and even 
if we plan to we can not guarantee that we’ll be accepted as a mentoring 
organization nor that your proposal would be selected. If you are still 
interested in contributing to our community please let us know if there is 
anything in particular you’d like to contribute to, what are your interests and 
skills, and what about our work and community appeals to you?

You should also take a look through our GitHub organizations (fluid-project 
 and inclusive-design 
) and the wiki 
. It would be good for you to start to 
understand what our goals and practices as a community are. If you are 
interested and have an idea of how you might contribute please get in touch 
again here on the mailing list and/or in our Matrix Channel 
.

Thanks
Justin

> On Nov 12, 2020, at 10:00 AM, Amulya dixit  wrote:
> 
> Hi , I'm Amulya , currently pursuing B.tech(CSE) , 2nd year from VIT, Bhopal 
> . I am a Open source contributor and a Enthusiast web developer, I want to 
> start contributing to Inclusive Design Institute Organisation for the GSOC 
> 2021 . Is there any projects currently going on related to a web development 
> so that I can work on that and make some contributions.Please let me know or 
> invite me to a slack channel related to it.
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: GSoC update and retrospective

[Justin Obara]

Hi Tony and Gregor,

Thanks for your feedback and input.

It seems that quite a few of the suggestions are things that would take place 
either in preparation for or during our next round of GSoC participation. We’ll 
likely meet early in the new year (Jan 2021) to discuss if we plan to Apply for 
GSoC 2021, and can discuss and action on some of those points at that time.

Regarding the suggestion for a getting started channel, we had some preliminary 
discussions related to that at our planning meeting this week. One suggestion 
was to have a welcome room in Matrix, where people can say hi, learn about the 
community, and ask questions to get started before moving into the other rooms. 
We plan to discuss this more at next weeks planning meeting (Nov 24, 2020 
starting at 11:30am ET). 

Thanks
Justin

> On Oct 28, 2020, at 6:38 AM, Tony Atkins  wrote:
> 
> Hi, All.
> 
> A few thoughts:
>  
> Regarding GSoC 2020 (and past iterations if you like)
> What did we do well?
> What can we do better?
> What are ways we can improve?
> 
> Although there was a lot of time required for the community bonding and 
> application period, I was very pleased with the candidate we finally found 
> for the project I worked on.  If I had to focus on any area for us to 
> improve, it would be in improving the pipeline of candidates, and the way in 
> which they interact with the community, with a focus on finding engaged 
> candidates quickly, and without disrupting the community too much.
> 
> As a lot of you have discussed, the rush of GSoC candidates is disruptive to 
> the community's normal work.  I think we need to move at least some of the 
> interactions with GSoC students out of #fluid-work and #fluid-tech, perhaps 
> to a new #fluid-howto or #fluid-getting-started where the channel can be 
> focused on learning Infusion and the community practices.  We might also want 
> a channel just for discussions of the proposals and the mechanics of the GSoC 
> application process.  We could also flip that and take more project-related 
> practical discussions out of #fluid-work, leaving that as a more general 
> space for learning (and identifying issues with) Infusion. Candidates who 
> manage to engage can transition to taking on tasks and communicating in 
> #fluid-work or other more central channels.
> 
> I like the idea about focused onboarding activities, one idea would be to 
> take them through one or two tutorials, and perhaps take them through 
> submitting updates for issues they encounter.  I was also thinking of 
> reducing the work for mentors by publishing office hours where the GSoC 
> channels are monitored more closely, perhaps in a rota so that not every 
> mentor has to monitor the list all the time.  Other mentors can be brought in 
> by @ mention as needed.
> 
> I also think we need to be much firmer about the application process.  At 
> least for my project there were far too many late and lower quality 
> applications.  It would be better for candidates and mentors if we had our 
> own parallel requirements such as:
> Suggesting that they should have gone through the Infusion tutorials by X 
> point.
> Suggesting that they should have taken on a sample issue or submitted a work 
> sample by Y point.
> Suggesting that they submit a draft of their proposal a week or two earlier 
> than the Google deadlines if they expect our feedback.
>  Within the rules of GSoC, we need to get good at letting people who don't 
> meet our requirements know that they're probably better off trying again next 
> year rather than rushing to figure it all out in the last few days.
> 
> Regarding GSoC 2021
> What are your thoughts on the changes?
> Does GSoC meet our needs and goals, and are we using it in a way that aligns 
> with their goals?
> 
> I got an awful lot out of working on GSoC this year, and that's set the bar 
> fairly high for me in the future.  The candidate I selected was the only one 
> who successfully engaged with Infusion during the bonding period, and even 
> then it was a challenge to finish in time.  I think the shorter working 
> period would require us to only accept candidates who successfully 
> demonstrate that they've already made their way through most of the required 
> learning curves.
> 
> One way to do this would be to have challenges or starter issues available, 
> perhaps specific to the skills required for the project.  Another approach 
> would be to screen by experience and work primarily with third and fourth 
> year undergrads, master's and PhD students.  Another would be to actively 
> recruit previous candidates for a second summer with us.
> 
> I think we should meet well in advance of the next GSoC to discuss what we 
> 

The Fluid Project has moved from IRC to Matrix / Element

[Justin Obara]

Hi Everyone,

The Fluid Project is now using Matrix <https://matrix.org/> / Element 
<https://element.io/> for our online collaborative discussions. Please see the 
Matrix Channel <https://wiki.fluidproject.org/display/fluid/Matrix+Channel> 
wiki page for information about the various rooms available. Past logs for the 
IRC Channels are available in the fluid-irc-logs 
<https://github.com/fluid-project/fluid-irc-logs> git repo.

Thanks everyone and hope to see you on Matrix.
Justin

> On Nov 10, 2020, at 3:15 PM, Justin Obara  wrote:
> 
> Hi Everyone,
> 
> We’ve been evaluating Matrix/Element for about two weeks now. It seems that 
> the majority of conversations are now taking place in Matrix. I haven’t heard 
> any show stopper issues as of yet, but please do weigh in on your experience. 
> We’re currently still on track to switch to Matrix as our primary synchronous 
> communication channel on Nov 16. 
> 
> Things to note:
> 
> There have been some connection and verification issues here and there, but 
> they seem to have resolved on their own. Possibly related to updates.
> While Matrix rooms support guest access, it doesn’t seem that Element or 
> possibly any other web client support guest accounts.
> 
> Thanks
> Justin
> 
>> On Oct 26, 2020, at 9:27 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> As a follow up, I’ve started a wiki page about Matrix with some general 
>> information for connecting to our channels. 
>> 
>> https://wiki.fluidproject.org/display/fluid/Matrix+Channel 
>> <https://wiki.fluidproject.org/display/fluid/Matrix+Channel>
>> 
>> Thanks
>> Justin
>> 
>>> On Oct 26, 2020, at 9:10 AM, Justin Obara >> <mailto:obara.jus...@gmail.com>> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> At the lightning talk last Thursday (Oct 22) the community was introduced 
>>> to Matrix <https://matrix.org/> / Element <https://element.io/> as a 
>>> potential alternative to IRC. Some key takeaways:
>>> 
>>> Like IRC Matrix is a protocol that supports use with a variety of clients
>>> Element is a client for accessing Matrix
>>> Matrix and Element are both open source projects
>>> Mozilla made the switch Matrix at the end of 2019
>>> Mozilla worked with Element to improve accessibility
>>> Matrix/Element provide a more Slack like full featured synchronous 
>>> communication platform that includes options for audio/video calls
>>> 
>>> We have been finding that an increasing number of people joining our 
>>> community are expecting to use a modern chat platform for communication and 
>>> are having difficulty understanding/working with IRC. There are some IRC 
>>> clients that help bridge the gap, such as irccloud.com 
>>> <http://irccloud.com/> however, they only benefit those using a similar 
>>> client and are limited by the protocol itself.
>>> 
>>> As of last Thursday we’ve opened up a Fluid Project Matrix community 
>>> <https://matrix.to/#/+fluid-project:matrix.org> and matching rooms for the 
>>> purpose of evaluating Matrix. However, at the moment, the IRC channels are 
>>> still our primary means of synchronous communication.
>>> 
>>> The proposal is to spend the next two weeks evaluating Matrix. Please 
>>> provide feedback on your experience. If there are no show stoppers we plan 
>>> to switch to Matrix as our primary means of synchronous communication 
>>> starting Nov 16. At that point we’ll also explore setting up a bridge 
>>> between Matrix and IRC to help with the transition.
>>> 
>>> Thanks
>>> Justin
>>> 
>>>> On Oct 20, 2020, at 11:46 AM, Ned Zimmerman >>> <mailto:nzimmer...@ocadu.ca>> wrote:
>>>> 
>>>> Hi all,
>>>>  
>>>> Colin, Gio, Justin, and myself have been exploring Matrix 
>>>> <https://matrix.org/> / Element <https://element.io/> as an alternative to 
>>>> IRC for IDRC and Fluid Project chat. Mozilla made the switch 
>>>> <https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620>
>>>>  from IRC to Matrix in December, and we’ve looked at their criteria and 
>>>> evaluation of Matrix and Element (particularly around the client’s 
>>>> accessibility, as documented by Marco Zehe 
>>>> <https://www.marcozehe.de/how-to-use-element-and-matrix-with-a-screen-reader/>)
>>>>  as well as trying the service ourselve

Re: Considering a move from IRC to Matrix / Element

[Justin Obara]

Hi Everyone,

We’ve been evaluating Matrix/Element for about two weeks now. It seems that the 
majority of conversations are now taking place in Matrix. I haven’t heard any 
show stopper issues as of yet, but please do weigh in on your experience. We’re 
currently still on track to switch to Matrix as our primary synchronous 
communication channel on Nov 16. 

Things to note:

There have been some connection and verification issues here and there, but 
they seem to have resolved on their own. Possibly related to updates.
While Matrix rooms support guest access, it doesn’t seem that Element or 
possibly any other web client support guest accounts.

Thanks
Justin

> On Oct 26, 2020, at 9:27 AM, Justin Obara  wrote:
> 
> As a follow up, I’ve started a wiki page about Matrix with some general 
> information for connecting to our channels. 
> 
> https://wiki.fluidproject.org/display/fluid/Matrix+Channel 
> <https://wiki.fluidproject.org/display/fluid/Matrix+Channel>
> 
> Thanks
> Justin
> 
>> On Oct 26, 2020, at 9:10 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Hi Everyone,
>> 
>> At the lightning talk last Thursday (Oct 22) the community was introduced to 
>> Matrix <https://matrix.org/> / Element <https://element.io/> as a potential 
>> alternative to IRC. Some key takeaways:
>> 
>> Like IRC Matrix is a protocol that supports use with a variety of clients
>> Element is a client for accessing Matrix
>> Matrix and Element are both open source projects
>> Mozilla made the switch Matrix at the end of 2019
>> Mozilla worked with Element to improve accessibility
>> Matrix/Element provide a more Slack like full featured synchronous 
>> communication platform that includes options for audio/video calls
>> 
>> We have been finding that an increasing number of people joining our 
>> community are expecting to use a modern chat platform for communication and 
>> are having difficulty understanding/working with IRC. There are some IRC 
>> clients that help bridge the gap, such as irccloud.com 
>> <http://irccloud.com/> however, they only benefit those using a similar 
>> client and are limited by the protocol itself.
>> 
>> As of last Thursday we’ve opened up a Fluid Project Matrix community 
>> <https://matrix.to/#/+fluid-project:matrix.org> and matching rooms for the 
>> purpose of evaluating Matrix. However, at the moment, the IRC channels are 
>> still our primary means of synchronous communication.
>> 
>> The proposal is to spend the next two weeks evaluating Matrix. Please 
>> provide feedback on your experience. If there are no show stoppers we plan 
>> to switch to Matrix as our primary means of synchronous communication 
>> starting Nov 16. At that point we’ll also explore setting up a bridge 
>> between Matrix and IRC to help with the transition.
>> 
>> Thanks
>> Justin
>> 
>>> On Oct 20, 2020, at 11:46 AM, Ned Zimmerman >> <mailto:nzimmer...@ocadu.ca>> wrote:
>>> 
>>> Hi all,
>>>  
>>> Colin, Gio, Justin, and myself have been exploring Matrix 
>>> <https://matrix.org/> / Element <https://element.io/> as an alternative to 
>>> IRC for IDRC and Fluid Project chat. Mozilla made the switch 
>>> <https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620>
>>>  from IRC to Matrix in December, and we’ve looked at their criteria and 
>>> evaluation of Matrix and Element (particularly around the client’s 
>>> accessibility, as documented by Marco Zehe 
>>> <https://www.marcozehe.de/how-to-use-element-and-matrix-with-a-screen-reader/>)
>>>  as well as trying the service ourselves. At this point, we’d like to 
>>> schedule a lightning talk for this Thursday (October 22) after standup to 
>>> share what we’ve found and get feedback from the broader community before 
>>> we move forward any further.
>>>  
>>> In the meantime, please feel free to explore at the links I shared in this 
>>> message and if you have any questions you’d like to put on the table for 
>>> the lightning talk and following discussion you can add them to the Google 
>>> Doc: 
>>> https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit#heading=h.9c0j4nlphmwf
>>>  
>>> <https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit#heading=h.9c0j4nlphmwf>
>>>  
>>> Cheers,
>>> Ned
>>> —
>>> Ned Zimmerman (he/him)
>>> Senior Inclusive Developer
>>&

Re: Changes to Atlassian products

[Justin Obara]

Maybe we should review our current plugins and evaluate if we really require 
them, and/or if there is functionality or free plugins in the cloud version 
that replaces the need for the one we’re currently using.

Thanks
Justin

> On Nov 10, 2020, at 9:43 AM, Giovanni Tirloni  wrote:
> 
> Hi Justin,
> 
> I looked for the plugins in the marketplace but I was only able to install 
> the following:
> 
> 
> 
> We'll probably have to re-apply to get open-source licenses for them since 
> they're paid.
> 
> Additionally, I couldn't find a way to transfer our existing licenses over to 
> the cloud installation. It seems each plugin installed gets a new license 
> number that can't be changed.
> 
> I think it's very likely we'll face some disruption in functionality.
> 
> ---
> 
> I was re-reading the FAQ <https://www.atlassian.com/migration/faqs> about 
> this change in Atlassian's policy and it says the following:
> 
> Server customers will have access to maintenance and support for an 
> additional three years, ending February 2, 2024 PT
> 
> So, I'm thinking that if they will provide maintenance and security updates 
> until 2024 we don't really need to make this migration right now.
> 
> My initial reading of the situation was that they would halt all development 
> in February 2021 but that doesn't seem to be the case.
> 
> From: Justin Obara 
> Sent: Monday, November 9, 2020 22:18
> To: Giovanni Tirloni 
> Cc: fluid-work@lists.idrc.ocad.ca 
> Subject: Re: Changes to Atlassian products
>  
> Hi Gio,
> 
> Thanks for working on this. It’ll help us get used to the new URLs and etc. I 
> think the timing is fine, but you should probably warn the AIHEC group. Not 
> sure, how to get a hold of them though, maybe through Jutta?
> 
> Will we be losing any functionality, e.g. plugins that aren’t supported 
> anymore?
> 
> Thanks
> Justin
> 
> > On Nov 9, 2020, at 6:00 PM, Antranig Basman  
> > wrote:
> > 
> > I like the idea of the redirects + load balancer and for me, given I am now 
> > a family man, the weekend is a perfectly fine time for that migration work. 
> > Thanks so much for looking into it!
> > 
> > Cheers,
> > 
> > Antranig
> > 
> > On 09/11/2020 22:51, Giovanni Tirloni wrote:
> >> One alternative that I've been researching is to migrate JIRA/Confluence 
> >> to the cloud and keep a load balancer on our infrastructure doing the HTTP 
> >> redirects.
> >> issues.fluidproject.org/$1 -> fluidproject.atlassian.net/$1
> >> wiki.fluidproject.org/$1 -> fluidproject.atlassian.net/wiki/$1
> >> I think this would be a viable solution and could give us more time to 
> >> plan a migration to some other system if desired.
> >> To work on that, I need to shut down the wiki/issues websites while the 
> >> migration is happening. Would this weekend be a good time to work on that? 
> >> Any concerns?
> > ___
> > fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> > To unsubscribe, change settings or access archives,
> > see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> > <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Changes to Atlassian products

[Justin Obara]

Hi Gio,

Thanks for working on this. It’ll help us get used to the new URLs and etc. I 
think the timing is fine, but you should probably warn the AIHEC group. Not 
sure, how to get a hold of them though, maybe through Jutta?

Will we be losing any functionality, e.g. plugins that aren’t supported anymore?

Thanks
Justin

> On Nov 9, 2020, at 6:00 PM, Antranig Basman  
> wrote:
> 
> I like the idea of the redirects + load balancer and for me, given I am now a 
> family man, the weekend is a perfectly fine time for that migration work. 
> Thanks so much for looking into it!
> 
> Cheers,
> 
> Antranig
> 
> On 09/11/2020 22:51, Giovanni Tirloni wrote:
>> One alternative that I've been researching is to migrate JIRA/Confluence to 
>> the cloud and keep a load balancer on our infrastructure doing the HTTP 
>> redirects.
>> issues.fluidproject.org/$1 -> fluidproject.atlassian.net/$1
>> wiki.fluidproject.org/$1 -> fluidproject.atlassian.net/wiki/$1
>> I think this would be a viable solution and could give us more time to plan 
>> a migration to some other system if desired.
>> To work on that, I need to shut down the wiki/issues websites while the 
>> migration is happening. Would this weekend be a good time to work on that? 
>> Any concerns?
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Repository permissions

[Justin Obara]

Hi everyone,

I’ve gone through and made some adjustments to the teams and permissions for 
our repositories. I’ve added all of the members to a team and given it “Triage” 
permission. Mostly this will add the ability to manage GitHub Issues and 
request reviews on PRs. (See: Repository permission levels for an organization 
).
 Unfortunately this isn’t an automatic process so we’ll have to keep things 
updated as new members and repos are added.

I’ve also cleaned up a few of the teams and members. Please let me know if you 
are missing access that you were expecting.

For our fluid-project repos we have a Maintainers team that is constructed of 
those who gained committer 
 access to the 
Fluid Community. We may want to consider if we should split out our access 
levels into groups of repositories. For example our websites have a different 
method for gaining commit access than does Infusion. Should the current set of 
maintainers have push access to all repos or just a certain subset? We’ve also 
been working on a set of a la carte governance options 
 that 
different projects/repos may pick from and potentially move between over time.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Feedback after getting familiar with the community

[Justin Obara]

Hello Joel,

Thanks for your continued interest. 

By project I assume you are referring to GSoC project. At this point GSoC 2021 
was just recently announced. Our community has yet to decide what projects 
we’ll run or even if we will apply for GSoC 2021, and there is no guarantee 
that we’ll get accepted if we do apply. GSoC 2021 will be different from past 
years too, so it’s hard to predict at this point what we’ll be aiming for. 

The primary goal of GSoC is to introduce new, diverse contributors to open 
source communities, and for those contributors to become a part of those 
communities. The point here is that it’s most important to become a part of the 
community, be engaged, understand the goals, the processes, the tools we use 
and etc. As I mentioned to you before, find something that you’re interested in 
contributing too, and reach out to those in the community involved with it to 
find out how you can best contribute.

Thanks
Justin

> On Nov 4, 2020, at 4:28 AM, Fokou Joel  wrote:
> 
> Hi everyone!
> Hope you're doing well!
> Sorry for the silence during these days. In fact I was trying to get familiar 
> with this amazing organization. At least I got some best points about it. But 
> nevertheless, I have two questions that I will really appreciate if I get 
> answers. The first one is what is the format if one wants to write a proposal 
> for project. The second one is, I wish to know if it is start looking at the 
> past projects and try to solve them is the best way to start or not given 
> thant I am new in the community.
> Thank you for your attention
> Joel
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Lighting Talk: Sass

[Justin Obara]

Hi Everyone,

Sorry the Lightning talk about Sass will be pushed back to Nov 12, 2020. This 
week (Nov 5) Lisa will be leading us in an exercise about alt text.

Thanks
Justin

> On Oct 29, 2020, at 12:57 PM, Justin Obara  wrote:
> 
> Infusion, with work on FLUID-6496 
> <https://github.com/fluid-project/infusion/pull/1024>, and many of our recent 
> websites have moved to using Sass <https://sass-lang.com/> as the CSS 
> pre-processor. On Thursday November 5, 2020 (~12:00pm ET) Ned will lead a 
> lightning talk to introduce Sass and answer questions you may have about it.
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Lighting Talk: Sass

[Justin Obara]

Infusion, with work on FLUID-6496 
, and many of our recent 
websites have moved to using Sass  as the CSS 
pre-processor. On Thursday November 5, 2020 (~12:00pm ET) Ned will lead a 
lightning talk to introduce Sass and answer questions you may have about it.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Request: Feedback about Vagrant boxes

[Justin Obara]

I’m not sure really. We might lose some of the local browser run options, but 
that’s it. It would probably be the same as what we’re running in CI and 
vagrant at the moment. That is, Firefox and Chrome. 

Thanks
Justin

> On Oct 27, 2020, at 3:19 PM, Colin Clark  wrote:
> 
> Is there anything stopping us from moving to headless browsers only, out of 
> curiosity?
> 
> Colin
> 
>> On Oct 27, 2020, at 2:38 PM, Justin Obara  wrote:
>> 
>> +1  Some of our repos, like infusion, have a vagrant setup for running the 
>> tests locally. If we can move to only running against headless browsers we 
>> might reasonably be able to drop the vagrant setup.
>> 
>> Thanks
>> Justin
>> 
>>> On Oct 27, 2020, at 12:35 PM, Giovanni Tirloni >> <mailto:gtirl...@ocadu.ca>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Fedora 33 just got released and that means Fedora 31 is going out of 
>>> support. Our latest vagrant box is based on it so we have to work on 
>>> updating it as well.
>>> 
>>> Our CI/CD is not using Vagrant anymore but I understand developers might 
>>> still be relying on the Vagrant boxes for development. Especially those on 
>>> macOS and Windows.
>>> 
>>> I wanted to quickly assess the situation by requesting that people using 
>>> the Vagrant boxes just reply with a quick "+1" to this email if you're 
>>> using them (feel free to add a quick note about how you use it, that'd be 
>>> great). Also, any additional feedback would be great!
>>> 
>>> That will help me prioritize the upgrade to Fedora 33. It has some exciting 
>>> features: https://fedoramagazine.org/announcing-fedora-33/ 
>>> <https://fedoramagazine.org/announcing-fedora-33/>
>>> 
>>> Cheers,
>>> Giovanni Tirloni
>>> DevOps Engineer
>>> Inclusive Design Research Centre, OCAD University
>>> https://idrc.ocadu.ca 
>>> <https://idrc.ocadu.ca/>___
>>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>>> <mailto:fluid-work@lists.idrc.ocad.ca>
>>> To unsubscribe, change settings or access archives,
>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
>> ___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Request: Feedback about Vagrant boxes

[Justin Obara]

+1  Some of our repos, like infusion, have a vagrant setup for running the 
tests locally. If we can move to only running against headless browsers we 
might reasonably be able to drop the vagrant setup.

Thanks
Justin

> On Oct 27, 2020, at 12:35 PM, Giovanni Tirloni  wrote:
> 
> Hi all,
> 
> Fedora 33 just got released and that means Fedora 31 is going out of support. 
> Our latest vagrant box is based on it so we have to work on updating it as 
> well.
> 
> Our CI/CD is not using Vagrant anymore but I understand developers might 
> still be relying on the Vagrant boxes for development. Especially those on 
> macOS and Windows.
> 
> I wanted to quickly assess the situation by requesting that people using the 
> Vagrant boxes just reply with a quick "+1" to this email if you're using them 
> (feel free to add a quick note about how you use it, that'd be great). Also, 
> any additional feedback would be great!
> 
> That will help me prioritize the upgrade to Fedora 33. It has some exciting 
> features: https://fedoramagazine.org/announcing-fedora-33/ 
> 
> 
> Cheers,
> Giovanni Tirloni
> DevOps Engineer
> Inclusive Design Research Centre, OCAD University
> https://idrc.ocadu.ca 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

GSoC update and retrospective

[Justin Obara]

Hi everyone,

As you probably know we participated in GSoC 
 2020 this year. Despite the pandemic the 
students and mentors were able to complete the projects. I applaud them all for 
their hard work and persistence. 

Gamepad Navigator 
fluidic-11ty 

GSoC just publicly announced GSoC 2021 
 with some major updates, so 
it seems like a good time to reflect back on our experience this year and think 
forward to the changes coming.

For GSoC 2021 they are making changes to “...help meet the #1 goal of GSoC - 
bring new, diverse contributors into your communities that stay in your 
communities after their GSoC program ends.”

Smaller project sizes - shortened from 350hr to 175hr
Shorted coding period - down to 10 weeks from 12, but with more flexibility for 
how the mentors and students would like to spread the work out over that time 
period
Reduced number of evaluations - 2 instead of 3
Expanded eligibility requirements - open those 18 years and older who are 
currently enrolled or accepted to a post secondary program as of May 17, 2021 
or graduated from a post-secondary academic program between Dec 1, 2020 and May 
17, 2021. This not only includes accredited university programs but also 
licensed code camps, community colleges, and more.

I’d like to seed the conversation with a few discussion points below, but feel 
free to talk about other things.

Regarding GSoC 2020 (and past iterations if you like)
What did we do well?
What can we do better?
What are ways we can improve?
Regarding GSoC 2021
What are your thoughts on the changes?
Does GSoC meet our needs and goals, and are we using it in a way that aligns 
with their goals?

Thanks
Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Default branch name in GitHub

[Justin Obara]

The branches for fluid-lab <https://github.com/fluid-lab>  inclusive-design 
<https://github.com/inclusive-design/> and fluid-project 
<https://github.com/fluid-project> have all been updated to remove the “master” 
branch in favour of “main”. There were some repos that didn’t use “master”; 
those have been left as is. For those that now have “main” as the default. I’ve 
made PRs to many of them, but there may still be some stray “master” references 
in some repos. 

It seems that links to the “master" branch will redirect to “main", so our 
external linking should be okay. However, as we find references to them in code 
or otherwise, we should update as needed.

Thanks
Justin



> On Oct 20, 2020, at 12:53 PM, Justin Obara  wrote:
> 
> Thanks for all the feedback. I also discussed this at the planning meeting 
> today and was met with similar responses. I plan to begin migration to “main” 
> for all of our non-archived git repositories. The process isn’t difficult but 
> we have a lot of repos, so it may take some time.
> 
> If you have not yet had a chance to provide feedback or raise a concern, 
> please feel free to continue the discussion.
> 
> Thanks
> Justin
> 
>> On Oct 20, 2020, at 11:26 AM, Joseph Scheuhammer > <mailto:cl...@alum.mit.edu>> wrote:
>> 
>> +1
>> 
>> On 2020-10-20 9:52 a.m., Colin Clark wrote:
>>> I think “main” is a good name too. I’m glad this is only a convention
>>> in Git so we’re free to choose. 
>>> 
>>> Colin
>>> 
>>>> On Oct 20, 2020, at 9:49 AM, Giovanni Tirloni >>> <mailto:gtirl...@ocadu.ca>> wrote:
>>>> 
>>>> 
>>>> +1 from me!
>>>> 
>>>> Another helpful blog
>>>> post: 
>>>> https://www.hanselman.com/blog/easily-rename-your-git-default-branch-from-master-to-main
>>>>  
>>>> <https://www.hanselman.com/blog/easily-rename-your-git-default-branch-from-master-to-main>
>>>> 
>>>> ----
>>>> *From:* fluid-work >>> <mailto:fluid-work-boun...@lists.idrc.ocad.ca>> on behalf
>>>> of Ned Zimmerman mailto:nzimmer...@ocadu.ca>>
>>>> *Sent:* Tuesday, October 20, 2020 10:30
>>>> *To:* Michelle D'Souza >>> <mailto:michelle...@gmail.com>>; Justin Obara
>>>> mailto:obara.jus...@gmail.com>>
>>>> *Cc:* fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@lists.idrc.ocad.ca> 
>>>> mailto:fluid-work@lists.idrc.ocad.ca>>
>>>> *Subject:* Re: Default branch name in GitHub
>>>>  
>>>> 
>>>> I’m in full support of this!
>>>> 
>>>>  
>>>> 
>>>> Cheers,
>>>> 
>>>> Ned
>>>> 
>>>> —
>>>> 
>>>> Ned Zimmerman (he/him)
>>>> 
>>>> Senior Inclusive Developer
>>>> 
>>>> Inclusive Design Research Centre, OCAD University
>>>> 
>>>> https://idrc.ocadu.ca <https://idrc.ocadu.ca/>
>>>> 
>>>>  
>>>> 
>>>> *From: *fluid-work 
>>>> *Date: *Tuesday, October 20, 2020 at 10:29 AM
>>>> *To: *Justin Obara 
>>>> *Cc: *fluid-work@lists.idrc.ocad.ca 
>>>> *Subject: *Re: Default branch name in GitHub
>>>> 
>>>> Let’s switch to using “main”. It’s easy to do and more
>>>> inclusive. 
>>>> https://dev.to/afrodevgirl/replacing-master-with-main-in-github-2fjf
>>>> 
>>>>  
>>>> 
>>>> Michelle
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> 
>>>> 
>>>>On Oct 20, 2020, at 9:17 AM, Justin Obara >>> <mailto:obara.jus...@gmail.com>
>>>><mailto:obara.jus...@gmail.com <mailto:obara.jus...@gmail.com>>> wrote:
>>>> 
>>>> 
>>>> 
>>>>While this has actually been in effect since Oct 1 I just now
>>>>realized that by default GitHub creates new repositories using
>>>>“main” instead of “master”. I’m not intending to weigh in on the
>>>>naming debate here, but I do think we need consistency. 
>>>> 
>>>> 
>>>> 
>>>>For details about the name change and how to manage it,
>>>>see https://github.com/github/renaming 
>>>> <https://github.com/github/renaming>
>&

Re: Contribute on WeCount Team Page and get more about JIRA issues Tracker

[Justin Obara]

Hello Fokou Joel,

Regarding JIRA  you’ll 
need to create an account. There should be a login/signup option on the landing 
page, as well as in the top right hand corner. However, the WeCount project 
does not use JIRA, they use GitHub Issues 
 in the 
repo itself, so you do not need to use JIRA for that.

Thanks
Justin

> On Oct 23, 2020, at 5:12 PM, Fokou Joel  wrote:
> 
> Hello everyone
> I'm Fokou Joel, I introduced myself four days ago in the community. From the 
> replies, I have two main point I really wish to get more information about. 
> Firstly, I visited the planning page and I saw the projects you are currently 
> working on. I wish to contribute on the issue for creating WeCount Team Page 
> and I don't know how to get started, please as I mentioned before, I am new 
> in the community. The second point is that, I wish know how to manage the 
> JIRA issues Tracker. I'd be very happy if someone could just help me. Thank 
> you
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Considering a move from IRC to Matrix / Element

[Justin Obara]

As a follow up, I’ve started a wiki page about Matrix with some general 
information for connecting to our channels. 

https://wiki.fluidproject.org/display/fluid/Matrix+Channel 
<https://wiki.fluidproject.org/display/fluid/Matrix+Channel>

Thanks
Justin

> On Oct 26, 2020, at 9:10 AM, Justin Obara  wrote:
> 
> Hi Everyone,
> 
> At the lightning talk last Thursday (Oct 22) the community was introduced to 
> Matrix <https://matrix.org/> / Element <https://element.io/> as a potential 
> alternative to IRC. Some key takeaways:
> 
> Like IRC Matrix is a protocol that supports use with a variety of clients
> Element is a client for accessing Matrix
> Matrix and Element are both open source projects
> Mozilla made the switch Matrix at the end of 2019
> Mozilla worked with Element to improve accessibility
> Matrix/Element provide a more Slack like full featured synchronous 
> communication platform that includes options for audio/video calls
> 
> We have been finding that an increasing number of people joining our 
> community are expecting to use a modern chat platform for communication and 
> are having difficulty understanding/working with IRC. There are some IRC 
> clients that help bridge the gap, such as irccloud.com <http://irccloud.com/> 
> however, they only benefit those using a similar client and are limited by 
> the protocol itself.
> 
> As of last Thursday we’ve opened up a Fluid Project Matrix community 
> <https://matrix.to/#/+fluid-project:matrix.org> and matching rooms for the 
> purpose of evaluating Matrix. However, at the moment, the IRC channels are 
> still our primary means of synchronous communication.
> 
> The proposal is to spend the next two weeks evaluating Matrix. Please provide 
> feedback on your experience. If there are no show stoppers we plan to switch 
> to Matrix as our primary means of synchronous communication starting Nov 16. 
> At that point we’ll also explore setting up a bridge between Matrix and IRC 
> to help with the transition.
> 
> Thanks
> Justin
> 
>> On Oct 20, 2020, at 11:46 AM, Ned Zimmerman > <mailto:nzimmer...@ocadu.ca>> wrote:
>> 
>> Hi all,
>>  
>> Colin, Gio, Justin, and myself have been exploring Matrix 
>> <https://matrix.org/> / Element <https://element.io/> as an alternative to 
>> IRC for IDRC and Fluid Project chat. Mozilla made the switch 
>> <https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620>
>>  from IRC to Matrix in December, and we’ve looked at their criteria and 
>> evaluation of Matrix and Element (particularly around the client’s 
>> accessibility, as documented by Marco Zehe 
>> <https://www.marcozehe.de/how-to-use-element-and-matrix-with-a-screen-reader/>)
>>  as well as trying the service ourselves. At this point, we’d like to 
>> schedule a lightning talk for this Thursday (October 22) after standup to 
>> share what we’ve found and get feedback from the broader community before we 
>> move forward any further.
>>  
>> In the meantime, please feel free to explore at the links I shared in this 
>> message and if you have any questions you’d like to put on the table for the 
>> lightning talk and following discussion you can add them to the Google Doc: 
>> https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit#heading=h.9c0j4nlphmwf
>>  
>> <https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit#heading=h.9c0j4nlphmwf>
>>  
>> Cheers,
>> Ned
>> —
>> Ned Zimmerman (he/him)
>> Senior Inclusive Developer
>> Inclusive Design Research Centre, OCAD University
>> https://idrc.ocadu.ca 
>> <https://idrc.ocadu.ca/>___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> <mailto:fluid-work@lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Considering a move from IRC to Matrix / Element

[Justin Obara]

Hi Everyone,

At the lightning talk last Thursday (Oct 22) the community was introduced to 
Matrix  / Element  as a potential 
alternative to IRC. Some key takeaways:

Like IRC Matrix is a protocol that supports use with a variety of clients
Element is a client for accessing Matrix
Matrix and Element are both open source projects
Mozilla made the switch Matrix at the end of 2019
Mozilla worked with Element to improve accessibility
Matrix/Element provide a more Slack like full featured synchronous 
communication platform that includes options for audio/video calls

We have been finding that an increasing number of people joining our community 
are expecting to use a modern chat platform for communication and are having 
difficulty understanding/working with IRC. There are some IRC clients that help 
bridge the gap, such as irccloud.com however, they only benefit those using a 
similar client and are limited by the protocol itself.

As of last Thursday we’ve opened up a Fluid Project Matrix community 
 and matching rooms for the 
purpose of evaluating Matrix. However, at the moment, the IRC channels are 
still our primary means of synchronous communication.

The proposal is to spend the next two weeks evaluating Matrix. Please provide 
feedback on your experience. If there are no show stoppers we plan to switch to 
Matrix as our primary means of synchronous communication starting Nov 16. At 
that point we’ll also explore setting up a bridge between Matrix and IRC to 
help with the transition.

Thanks
Justin

> On Oct 20, 2020, at 11:46 AM, Ned Zimmerman  wrote:
> 
> Hi all,
>  
> Colin, Gio, Justin, and myself have been exploring Matrix 
>  / Element  as an alternative to 
> IRC for IDRC and Fluid Project chat. Mozilla made the switch 
> 
>  from IRC to Matrix in December, and we’ve looked at their criteria and 
> evaluation of Matrix and Element (particularly around the client’s 
> accessibility, as documented by Marco Zehe 
> )
>  as well as trying the service ourselves. At this point, we’d like to 
> schedule a lightning talk for this Thursday (October 22) after standup to 
> share what we’ve found and get feedback from the broader community before we 
> move forward any further.
>  
> In the meantime, please feel free to explore at the links I shared in this 
> message and if you have any questions you’d like to put on the table for the 
> lightning talk and following discussion you can add them to the Google Doc: 
> https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit#heading=h.9c0j4nlphmwf
>  
> 
>  
> Cheers,
> Ned
> —
> Ned Zimmerman (he/him)
> Senior Inclusive Developer
> Inclusive Design Research Centre, OCAD University
> https://idrc.ocadu.ca 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Default branch name in GitHub

[Justin Obara]

Thanks for all the feedback. I also discussed this at the planning meeting 
today and was met with similar responses. I plan to begin migration to “main” 
for all of our non-archived git repositories. The process isn’t difficult but 
we have a lot of repos, so it may take some time.

If you have not yet had a chance to provide feedback or raise a concern, please 
feel free to continue the discussion.

Thanks
Justin

> On Oct 20, 2020, at 11:26 AM, Joseph Scheuhammer  wrote:
> 
> +1
> 
> On 2020-10-20 9:52 a.m., Colin Clark wrote:
>> I think “main” is a good name too. I’m glad this is only a convention
>> in Git so we’re free to choose. 
>> 
>> Colin
>> 
>>> On Oct 20, 2020, at 9:49 AM, Giovanni Tirloni  wrote:
>>> 
>>> 
>>> +1 from me!
>>> 
>>> Another helpful blog
>>> post: 
>>> https://www.hanselman.com/blog/easily-rename-your-git-default-branch-from-master-to-main
>>> 
>>> ----
>>> *From:* fluid-work  on behalf
>>> of Ned Zimmerman 
>>> *Sent:* Tuesday, October 20, 2020 10:30
>>> *To:* Michelle D'Souza ; Justin Obara
>>> 
>>> *Cc:* fluid-work@lists.idrc.ocad.ca 
>>> *Subject:* Re: Default branch name in GitHub
>>>  
>>> 
>>> I’m in full support of this!
>>> 
>>>  
>>> 
>>> Cheers,
>>> 
>>> Ned
>>> 
>>> —
>>> 
>>> Ned Zimmerman (he/him)
>>> 
>>> Senior Inclusive Developer
>>> 
>>> Inclusive Design Research Centre, OCAD University
>>> 
>>> https://idrc.ocadu.ca
>>> 
>>>  
>>> 
>>> *From: *fluid-work 
>>> *Date: *Tuesday, October 20, 2020 at 10:29 AM
>>> *To: *Justin Obara 
>>> *Cc: *fluid-work@lists.idrc.ocad.ca 
>>> *Subject: *Re: Default branch name in GitHub
>>> 
>>> Let’s switch to using “main”. It’s easy to do and more
>>> inclusive. 
>>> https://dev.to/afrodevgirl/replacing-master-with-main-in-github-2fjf
>>> 
>>>  
>>> 
>>> Michelle
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> 
>>>On Oct 20, 2020, at 9:17 AM, Justin Obara >> <mailto:obara.jus...@gmail.com>
>>><mailto:obara.jus...@gmail.com <mailto:obara.jus...@gmail.com>>> wrote:
>>> 
>>> 
>>> 
>>>While this has actually been in effect since Oct 1 I just now
>>>realized that by default GitHub creates new repositories using
>>>“main” instead of “master”. I’m not intending to weigh in on the
>>>naming debate here, but I do think we need consistency. 
>>> 
>>> 
>>> 
>>>For details about the name change and how to manage it,
>>>see https://github.com/github/renaming 
>>> <https://github.com/github/renaming>
>>> 
>>> 
>>> 
>>>What I’d propose is that we pick a name that the community is
>>>most comfortable with. Below are the tasks to address after a
>>>decision is made.
>>> 
>>> 
>>> 
>>>Options:
>>> 
>>> 
>>> 
>>>  * Keep Master:
>>> 
>>>  o Update the organization settings for the “Repository
>>>default branch” name
>>>  o Change any newly created repos to use “master” as the
>>>default branch
>>> 
>>>  * Use Main:
>>> 
>>>  o Update all existing repos to use “main” as the default repo
>>>  o Update our individual forks as needed
>>> 
>>>  * Use some other name:
>>> 
>>>  o Update the organization settings for the “Repository
>>>default branch” name
>>>  o Update all existing repos to use “main” as the default repo
>>>  o Update our individual forks as needed
>>> 
>>> 
>>> 
>>>Thanks
>>> 
>>>Justin
>>> 
>>>___
>>>fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>>> <mailto:fluid-work@lists.idrc.ocad.ca>
>>><mailto:fluid-work@lists.idrc.ocad.ca 
>>> <mailto:fluid-work@lists.idrc.ocad.ca>>
>>>To unsubscribe, change settings or access archives,
>>>see https://lists.idrc.ocad.ca/ma

Re: Changes to Atlassian products

[Justin Obara]

I wonder if the ILDH related issues are a good place to start with migrating 
from JIRA to GitHub Issues. We have been tracking issues for websites in GitHub 
Issues more recently and the ILDH currently has JIRAs tracked in two or three 
different JIRA projects. Also we’re starting to work on that project again. I 
was talking a bit with Ned about it in the IRC channel the other day and 
sounded like it would be preferred to use GitHub Issues going forward.

We should consider if we want to move all of the issues (closed and open), if 
there is an automated way to do the migration (I believe we’ll have to create 
our own script using the GitHub API), and what information we want to preserver.

The wiki is a really good question. My initial thought is that migrating to 
another wiki could be a nightmare, although this stackoverflow 
<https://stackoverflow.com/a/19280892> post suggests exporting as HTML and 
using Pandoc to convert to markdown for migration to GitHub Wiki. Breaking all 
of our links to the wiki is also really sad. I’m not sure what we can do about 
that though. 

Thanks
Justin


> On Oct 20, 2020, at 10:25 AM, Colin Clark  wrote:
> 
> Hi Justin and Gio,
> 
> Thanks for looking into this. It sounds like realistically we may have a few 
> different kinds of projects. Some have thousands of issues with lots of 
> detail, discussion, and history associated with them. Others may have a 
> smaller pool of issues. Maybe for that latter category, as we’ve already been 
> exploring, we can consider migrating to Github Issues. We can use them as to 
> evaluate whether migrating the larger projects will be feasible, or if we’ll 
> have to move to a more restricted cloud-hosted version of JIRA for those.
> 
> The other question is what we do with the wiki…
> 
> Colin
> 
>> On Oct 20, 2020, at 8:12 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Gio and I spoke a bit in the fluid-work IRC channel 
>> <http://irc-logs.fluidproject.org/#fluid-work/%23fluid-work.2020-10-20.log> 
>> this morning. Below is a quick summary:
>> 
>> People aren’t happy about forced migration and lack of custom domains for 
>> Atlassian Cloud
>> Atlassian said they’d review the roadmap for custom domains in January 2021
>> JIRA issue numbers will likely be preserved 
>> User accounts and workflows will be migrated
>> This seems like a good time to review our use of these tools and consider 
>> alternatives
>> 
>> Thanks
>> Justin
>> 
>>> On Oct 19, 2020, at 3:30 PM, Giovanni Tirloni >> <mailto:gtirl...@ocadu.ca>> wrote:
>>> 
>>> Hi Justin,
>>> 
>>> I've submitted a request for licenses for their cloud products so we can 
>>> assess the situation. The ETA is 3 business days to hear from them.
>>> 
>>> Re: impact. Unfortunately, it's not possible to use custom domains with 
>>> Atlassian Cloud products [0]. That means our links to wiki.fluidproject.org 
>>> <http://wiki.fluidproject.org/> and issues.fluidproject.org 
>>> <http://issues.fluidproject.org/> would be broken.
>>> 
>>> 0 - https://jira.atlassian.com/browse/CLOUD-6999 
>>> <https://jira.atlassian.com/browse/CLOUD-6999>
>>> 
>>> From: Justin Obara mailto:obara.jus...@gmail.com>>
>>> Sent: Monday, October 19, 2020 08:59
>>> To: Giovanni Tirloni mailto:gtirl...@ocadu.ca>>
>>> Cc: fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@lists.idrc.ocad.ca> 
>>> mailto:fluid-work@lists.idrc.ocad.ca>>
>>> Subject: Re: Changes to Atlassian products
>>>  
>>> Hi Gio,
>>> 
>>> Thanks for the update. I remember looking at their cloud offerings 
>>> pre-pandemic. It seemed like they still offered free cloud options for open 
>>> source projects. However, the plugins weren’t free anymore. Is that still 
>>> the case and do we actually need the plugins we’re currently using if we 
>>> migrate to the cloud? Also do you have a gauge on how else this might 
>>> affect us? For example will existing links to the wiki and JIRA break once 
>>> we move to the cloud?
>>> 
>>> Thanks
>>> Justin
>>> 
>>>> On Oct 16, 2020, at 8:41 PM, Giovanni Tirloni >>> <mailto:gtirl...@ocadu.ca>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> Atlassian will stop selling the Server version of their products. We use a 
>>>> self-hosted JIRA Server.
>>>> 
>>>> See the announcement and a timeline for the change here: 
>>>> 
>>>>

Default branch name in GitHub

[Justin Obara]

While this has actually been in effect since Oct 1 I just now realized that by 
default GitHub creates new repositories using “main” instead of “master”. I’m 
not intending to weigh in on the naming debate here, but I do think we need 
consistency. 

For details about the name change and how to manage it, see 
https://github.com/github/renaming 

What I’d propose is that we pick a name that the community is most comfortable 
with. Below are the tasks to address after a decision is made.

Options:

Keep Master:
Update the organization settings for the “Repository default branch” name
Change any newly created repos to use “master” as the default branch
Use Main:
Update all existing repos to use “main” as the default repo
Update our individual forks as needed
Use some other name:
Update the organization settings for the “Repository default branch” name
Update all existing repos to use “main” as the default repo
Update our individual forks as needed

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Changes to Atlassian products

[Justin Obara]

Gio and I spoke a bit in the fluid-work IRC channel 
<http://irc-logs.fluidproject.org/#fluid-work/%23fluid-work.2020-10-20.log> 
this morning. Below is a quick summary:

People aren’t happy about forced migration and lack of custom domains for 
Atlassian Cloud
Atlassian said they’d review the roadmap for custom domains in January 2021
JIRA issue numbers will likely be preserved 
User accounts and workflows will be migrated
This seems like a good time to review our use of these tools and consider 
alternatives

Thanks
Justin

> On Oct 19, 2020, at 3:30 PM, Giovanni Tirloni  wrote:
> 
> Hi Justin,
> 
> I've submitted a request for licenses for their cloud products so we can 
> assess the situation. The ETA is 3 business days to hear from them.
> 
> Re: impact. Unfortunately, it's not possible to use custom domains with 
> Atlassian Cloud products [0]. That means our links to wiki.fluidproject.org 
> <http://wiki.fluidproject.org/> and issues.fluidproject.org 
> <http://issues.fluidproject.org/> would be broken.
> 
> 0 - https://jira.atlassian.com/browse/CLOUD-6999 
> <https://jira.atlassian.com/browse/CLOUD-6999>
> 
> From: Justin Obara 
> Sent: Monday, October 19, 2020 08:59
> To: Giovanni Tirloni 
> Cc: fluid-work@lists.idrc.ocad.ca 
> Subject: Re: Changes to Atlassian products
>  
> Hi Gio,
> 
> Thanks for the update. I remember looking at their cloud offerings 
> pre-pandemic. It seemed like they still offered free cloud options for open 
> source projects. However, the plugins weren’t free anymore. Is that still the 
> case and do we actually need the plugins we’re currently using if we migrate 
> to the cloud? Also do you have a gauge on how else this might affect us? For 
> example will existing links to the wiki and JIRA break once we move to the 
> cloud?
> 
> Thanks
> Justin
> 
>> On Oct 16, 2020, at 8:41 PM, Giovanni Tirloni > <mailto:gtirl...@ocadu.ca>> wrote:
>> 
>> Hello,
>> 
>> Atlassian will stop selling the Server version of their products. We use a 
>> self-hosted JIRA Server.
>> 
>> See the announcement and a timeline for the change here: 
>> 
>> https://www.atlassian.com/migration/journey-to-cloud?jobid=104830907&subid=1515944789
>>  
>> <https://www.atlassian.com/migration/journey-to-cloud?jobid=104830907&subid=1515944789>
>> 
>> https://www.atlassian.com/migration/key-offering-changes?tab=server-dates#important-dates
>>  
>> <https://www.atlassian.com/migration/key-offering-changes?tab=server-dates#important-dates>
>> 
>> By Feb 2022 there will no more upgrades (new versions).
>> 
>> I think it's unrealistic to expect they will put any effort into releasing 
>> new functionality or anything outside critical bug fixes moving forward.
>> 
>> My initial impression is that we'd have to migrate to their cloud offering 
>> (like GPII?) or move to a different ticket system altogether.
>> 
>> Regards,
>> Giovanni
>> 
>> 
>> ___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> <mailto:fluid-work@lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Contribute the most interested organisation as developer

[Justin Obara]

Hi Joel,

Thanks for getting in touch and showing interest in our project. Could you 
please expand more on what makes you interested in our work and what types of 
things or areas you’d like to contribute to? Also how did you hear about us?

Regarding where to start. You found the mailing list, which is a good start. 
You can find a summary of things we are actively working on from the planning 
page  of the 
wiki. You may also wish to look over our GitHub organization 
 and JIRA issue tracker 
. We also hold regular 
community workshops and design crits 

  which you are welcome to join.

For other ways of communicating with us, please see the Get Involved 
 page. The IRC 
channel is a good place for real-time communication and here on the list for 
reaching more people in an asynchronous fashion.

Thanks
Justin

> On Oct 18, 2020, at 3:45 PM, Fokou Joel  wrote:
> 
> Good morning/evening everyone.
> I am Fokou Joel, software engineering student in university of Buea-Cameroon. 
> I have four years of experiences in web development (HTML5, CSS3, 
> JavaScript-ES6 and its subsequences libraries, ReactJS, NodeJS, PHP-Laravel), 
> mobile development advanced React Native and Java. I contributed to many 
> software development projects. I have also been trained by Coursera online 
> courses for most of the above programming languages. I found really 
> interesting to contribute to this amazing organisation given that I manage 
> its technologies. I will appreciate if someone point me where to start.
> Thank you beforehand
> Best regards
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: New Floeproject.org wireframe and site map

[Justin Obara]

Hi Jon,

Thanks for working on this. It’s great to see our sites updated and getting a 
refresh.

I like how the site is moving towards a unified design with our other sites. It 
will help keep things cohesive as one navigates across them. In that regard I 
wonder if a similar layout/architecture to the IDRC site 
 might help here. For example:

Put more information about FLOE on the landing page, maybe all of the “about” 
info if it isn’t too much.
Follow up with highlighted projects
Have three columns for resources, tools, and news

In the designs you’ve provided I find that the page feels long. The news takes 
the highest priority and the projects have been de-emphasized. Perhaps all of 
that was intentional, but there may be a way to give things easier access while 
highlighting a certain dimension. 

The short description of FLOE says: “FLOE provides resources to personalize how 
we each learn and to address barriers to self-aware, life-long learning.” I’d 
expect those resources and etc to be highlighted, but the news is the primary 
focus. 

The sort of tag line “Supporting learners, educators and curriculum producers 
in achieving one-size-fits-one learning design for the full diversity of 
learners” doesn’t really fit as placed. I’m not sure exactly, but perhaps 
re-wording or maybe grouping that with the “Designing for Diverse Learners” and 
expanding the description sentence with more info and moved into a section 
below.

Thanks
Justin


> On Oct 16, 2020, at 3:22 PM, Jonathan Hung  wrote:
> 
> Hello everyone,
>  
> Attached to this email is a PDF showing a wireframe of the Floe Project 
> website. This is work in progress and focuses mainly on content layout and 
> information architecture. I will describe the details of this work.
>  
> The goal of this redesign is two-fold:
> Make the site mobile friendly
> Ease navigation and content discovery with a modified information architecture
>  
> To accomplish this, much of the textual content of the home page is replaced 
> by content “cards” (“cards” are short excerpts linking to the full content, 
> and visually resembles a cue card). Cards are categorized into three main 
> headings: News, Resources, and Tools. Toward the bottom of the home page is a 
> fourth heading called “Projects” which lists a few of the current Floe 
> related projects. Under each of these headings is a link to see an index of 
> the relevant content such as an index of all news articles, or an index of 
> all projects.
>  
> The site map / content structure is shallow:
> Level 1 – home
> Level 2 – News index, Tools index, Resources index, and About
> Level 3 – Individual news articles, or pages describing the tool or resource. 
> Pages under about will include a contact page, and a project description page.
>  
> What’s next? Currently I am seeking any feedback on the work so far. Does the 
> content structure work, or is there a better organization? Does the content 
> on the home page capture the breadth of activities under the Floe Project, or 
> is there something missing?
>  
> I will begin working on wireframes for the individual content pages for news, 
> tools, resources, and projects next.
>  
> Best,
>  
> -Jon.
>  
>  
> ---
> Jonathan Hung, Inclusive Design Collaborator / Researcher
> Email: jh...@ocadu.ca 
> OCAD University
> Inclusive Design Research Centre
>  
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Changes to Atlassian products

[Justin Obara]

Hi Gio,

Thanks for the update. I remember looking at their cloud offerings 
pre-pandemic. It seemed like they still offered free cloud options for open 
source projects. However, the plugins weren’t free anymore. Is that still the 
case and do we actually need the plugins we’re currently using if we migrate to 
the cloud? Also do you have a gauge on how else this might affect us? For 
example will existing links to the wiki and JIRA break once we move to the 
cloud?

Thanks
Justin

> On Oct 16, 2020, at 8:41 PM, Giovanni Tirloni  wrote:
> 
> Hello,
> 
> Atlassian will stop selling the Server version of their products. We use a 
> self-hosted JIRA Server.
> 
> See the announcement and a timeline for the change here: 
> 
> https://www.atlassian.com/migration/journey-to-cloud?jobid=104830907&subid=1515944789
>  
> 
> 
> https://www.atlassian.com/migration/key-offering-changes?tab=server-dates#important-dates
>  
> 
> 
> By Feb 2022 there will no more upgrades (new versions).
> 
> I think it's unrealistic to expect they will put any effort into releasing 
> new functionality or anything outside critical bug fixes moving forward.
> 
> My initial impression is that we'd have to migrate to their cloud offering 
> (like GPII?) or move to a different ticket system altogether.
> 
> Regards,
> Giovanni
> 
> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Fwd: Hacktoberfest related spam

[Justin Obara]

Hi everyone,

Simon wrote up a detailed post about Hacktoberfest and dealing with related 
spam PRs. Please see below:

Thanks
Justin

> 
> Today is the start of October and the start of DigitalOcean's Hacktoberfest 
> program.
> 
> The Inclusive Cities website repository has received its first spam pull 
> request (https://github.com/inclusive-design/website-cities/pull/51/files). 
> It's likely that other projects will also see spam PRs, particularly website 
> repositories (CSS files seem to be a popular target).
> 
> In this email, I've written up a little about Hacktoberfest and how to report 
> spam pull requests.
> 
> What is Hacktoberfest?
> 
> - https://hacktoberfest.digitalocean.com/
> - DigitalOcean will send participants a t-shirt for making 4 pull requests 
> against any GitHub repository during the month of October
> 
> Spam
> 
> - The intention of the program is to promote contributions to open source 
> projects by offering a reward for making contributions
> - Unfortunately, it is easy to attempt to game the program by making pull 
> requests with insignificant changes as a PR does not have to be accepted to 
> qualify, only that it be made
> - Example spam PRs made against the WHATWG HTML spec working group website 
> repo: https://github.com/whatwg/html/pulls?q=is%3Apr+is%3Aclosed+label%3Aspam
> 
> How to report spam
> 
> - From the Hacktoberfest FAQ:
> 
> "As a maintainer, how should I handle spam pull requests?
> 
> We dislike seeing spam pull requests just as much as you, so please give them 
> an 'invalid' or 'spam' label and close them. Pull requests that contain a 
> label with the word 'invalid' or 'spam' won’t be counted toward 
> Hacktoberfest."
> 
> https://hacktoberfest.digitalocean.com/faq
> 
> Simon
> 
> --
> Simon Bates
> Senior Inclusive Developer
> Inclusive Design Research Centre, OCAD University
> https://idrc.ocadu.ca
> 

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Stylesheet linting

[Justin Obara]

Hi Tony,

I’ve filed an issue ( 
https://github.com/fluid-project/fluid-grunt-lint-all/issues/16 
<https://github.com/fluid-project/fluid-grunt-lint-all/issues/16> ).

Thanks
Justin

> On Oct 1, 2020, at 5:46 AM, Tony Atkins  wrote:
> 
> Hi, Justin.
> 
> It's an interesting idea, and would prepare us to explore things like 
> migrating away from Grunt entirely, which myself and others have long talked 
> about.
> 
> However,  we don't just check things covered by ESlint.  We have four or five 
> other tasks, and I'm not sure there are ESlint plugins to replace all of 
> them.  I'd rather not support and have to reconcile two types of 
> configuration if we can help it.
> 
> For example, ESlint has rules about which files to include and exclude.  
> Currently fluid-grunt-lint-all uses Grunt syntax for much of that, if we 
> disallowed that for ESlint, do we still support it for everything else?  Do 
> we come up with our own JSON configuration file for everything else?  Do we 
> also support ESLint configuration within that file?
> 
> Anyway, I think with a little discussion we can come up with answers to that 
> and sketch out the work, then it's just a question of who can/should do it.  
> Can you start us out by creating a ticket?
> 
> Cheers,
> 
> 
> Tony
> 
> 
> 
> On Mon, 28 Sep 2020 at 13:42, Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> Hi Tony,
> 
> If it isn’t already possible, it might be easier for a user of 
> fluid-grunt-lint-all to be able to use the standard config files, e.g. 
> eslintrc.json to configure the settings of the various fluid-grunt-lint-all 
> plugins. IDEs can be setup to use these configuration files to provide 
> linting during coding/writing. Also, it may be clearer for those coming into 
> the project to understand what and where to find the configuration. 
> 
> Thanks
> Justin
> 
>> On Sep 28, 2020, at 5:19 AM, Tony Atkins > <mailto:t...@raisingthefloor.org>> wrote:
>> 
>> Hi, Cindy.
>> 
>> When working on the plugin, I explicitly wanted to make sure that it was 
>> possible to configure settings per project.  As an example, here is the test 
>> fixture I use to confirm that I can pass a custom configuration option to 
>> each of the tasks that fluid-grunt-lint-all currently handles:
>> 
>> https://github.com/fluid-project/fluid-grunt-lint-all/blob/master/tests-Gruntfile-options-override.js
>>  
>> <https://github.com/fluid-project/fluid-grunt-lint-all/blob/master/tests-Gruntfile-options-override.js>
>> 
>> I would expect for any new tasks such as CSS linting to also provide the 
>> ability to configure new options per project.
>> 
>> Cheers,
>> 
>> 
>> Tony
>> 
>> On Fri, 25 Sep 2020 at 15:23, Cindy Li > <mailto:c...@ocadu.ca>> wrote:
>> One thought is, it might be helpful if fluid-grunt-lint-all could be 
>> flexible enough to allow the overriding of configurations, ideally for all 
>> linting tools it uses.
>> 
>> One example is, most of our projects uses 4 spaces as indentations but at 
>> least WeCount project uses tabs as indentations. The switch to tabs is to 
>> allow developers to define their own preferred mapping from a tab to spaces 
>> in their IDEs, for the inclusion purpose. ;)
>> 
>> Extending from it, individual projects may have their own linting 
>> requirements for their own reasons. It would be nice if fluid-grunt-lint-all 
>> could accommodate varied configurations.
>> 
>> Thanks.
>> 
>> Cindy
>> 
>>> On Sep 25, 2020, at 8:52 AM, Ned Zimmerman >> <mailto:nzimmer...@ocadu.ca>> wrote:
>>> 
>>> Thanks, Cindy. Having worked with the stylelint configuration on We Count, 
>>> what are your thoughts? Are there any changes you'd recommend?
>>> 
>>> Cheers,
>>> Ned
>>> —
>>> Ned Zimmerman (he/him)
>>> Senior Inclusive Developer
>>> Inclusive Design Research Centre, OCAD University
>>> https://idrc.ocadu.ca <https://idrc.ocadu.ca/>
>>> 
>>> On 2020-09-25, 9:26 AM, "Cindy Li" mailto:c...@ocadu.ca>> 
>>> wrote:
>>> 
>>>Great idea. +1
>>> 
>>>> On Sep 24, 2020, at 10:42 AM, Ned Zimmerman >>> <mailto:nzimmer...@ocadu.ca>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I wanted to propose that we create a shareable Stylelint configuration for 
>>>> Fluid projects along the lines of eslint-config-fluid. This could be added 
>>>

Re: Stylesheet linting

[Justin Obara]

Hi Tony,

If it isn’t already possible, it might be easier for a user of 
fluid-grunt-lint-all to be able to use the standard config files, e.g. 
eslintrc.json to configure the settings of the various fluid-grunt-lint-all 
plugins. IDEs can be setup to use these configuration files to provide linting 
during coding/writing. Also, it may be clearer for those coming into the 
project to understand what and where to find the configuration. 

Thanks
Justin

> On Sep 28, 2020, at 5:19 AM, Tony Atkins  wrote:
> 
> Hi, Cindy.
> 
> When working on the plugin, I explicitly wanted to make sure that it was 
> possible to configure settings per project.  As an example, here is the test 
> fixture I use to confirm that I can pass a custom configuration option to 
> each of the tasks that fluid-grunt-lint-all currently handles:
> 
> https://github.com/fluid-project/fluid-grunt-lint-all/blob/master/tests-Gruntfile-options-override.js
>  
> 
> 
> I would expect for any new tasks such as CSS linting to also provide the 
> ability to configure new options per project.
> 
> Cheers,
> 
> 
> Tony
> 
> On Fri, 25 Sep 2020 at 15:23, Cindy Li mailto:c...@ocadu.ca>> 
> wrote:
> One thought is, it might be helpful if fluid-grunt-lint-all could be flexible 
> enough to allow the overriding of configurations, ideally for all linting 
> tools it uses.
> 
> One example is, most of our projects uses 4 spaces as indentations but at 
> least WeCount project uses tabs as indentations. The switch to tabs is to 
> allow developers to define their own preferred mapping from a tab to spaces 
> in their IDEs, for the inclusion purpose. ;)
> 
> Extending from it, individual projects may have their own linting 
> requirements for their own reasons. It would be nice if fluid-grunt-lint-all 
> could accommodate varied configurations.
> 
> Thanks.
> 
> Cindy
> 
>> On Sep 25, 2020, at 8:52 AM, Ned Zimmerman > > wrote:
>> 
>> Thanks, Cindy. Having worked with the stylelint configuration on We Count, 
>> what are your thoughts? Are there any changes you'd recommend?
>> 
>> Cheers,
>> Ned
>> —
>> Ned Zimmerman (he/him)
>> Senior Inclusive Developer
>> Inclusive Design Research Centre, OCAD University
>> https://idrc.ocadu.ca 
>> 
>> On 2020-09-25, 9:26 AM, "Cindy Li" mailto:c...@ocadu.ca>> 
>> wrote:
>> 
>>Great idea. +1
>> 
>>> On Sep 24, 2020, at 10:42 AM, Ned Zimmerman >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> I wanted to propose that we create a shareable Stylelint configuration for 
>>> Fluid projects along the lines of eslint-config-fluid. This could be added 
>>> to fluid-grunt-lint-all and used as a starting point in various projects. 
>>> Stylelint is currently in use in the new IDRC website and in the We Count 
>>> website. I created a JIRA for this (FLUID-6555) and there are some relevant 
>>> links there. Eager to hear others' thoughts on this and I'm happy to start 
>>> working on it if it sounds like a good idea to others.
>>> 
>>> Cheers,
>>> Ned
>>> —
>>> Ned Zimmerman (he/him)
>>> Senior Inclusive Developer
>>> Inclusive Design Research Centre, OCAD University
>>> https://idrc.ocadu.ca 
>>> 
>>> ___
>>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>>> 
>>> To unsubscribe, change settings or access archives,
>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>>> 
>> 
>> 
> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Community Meeting ( Sep 22 ): GSoC 2020 Retrospective ** CANCELLED **

[Justin Obara]

Unfortunately we’ll need to reschedule the GSoC Retrospective. I’m not yet sure 
of when it will be rescheduled too, but will update the Community Meeting 
<https://wiki.fluidproject.org/display/fluid/Community+workshops+and+design+crits>
 page when it is. 

Thanks
Justin

> On Sep 21, 2020, at 9:17 AM, Justin Obara  wrote:
> 
> At this week’s Community Meeting 
> <https://wiki.fluidproject.org/display/fluid/Community+workshops> ( Sep 22, 
> 2020 ) we’ll be doing a retrospective on this year’s GSoC program. This is 
> both for those that mentored projects as well as those in the community, as 
> GSoC touched on our community in many ways.
> 
> Links:
> 
> Google Summer of Code 2020 with the Fluid Project 
> <https://wiki.fluidproject.org/display/fluid/Google+Summer+of+Code+2020+with+the+Fluid+Project>
> Gamepad Navigator <https://github.com/fluid-lab/gamepad-navigator>
> fluidic-11ty <https://github.com/fluid-project/fluidic-11ty>
> 
> Notes: Etherpad 
> <https://pad.inclusivedesign.ca/mypads/?/mypads/group/gsoc-dnq0jcb/pad/view/gsoc-2020-retrospective-pnr0je4>
> 
> 
> Time:
> 1:00 - 2:00pm ET
> 
> Location:
> Remotely: Zoom <https://ocadu.zoom.us/j/727986784>
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Sep 22 ): GSoC 2020 Retrospective

[Justin Obara]

At this week’s Community Meeting 
 ( Sep 22, 
2020 ) we’ll be doing a retrospective on this year’s GSoC program. This is both 
for those that mentored projects as well as those in the community, as GSoC 
touched on our community in many ways.

Links:

Google Summer of Code 2020 with the Fluid Project 

Gamepad Navigator 
fluidic-11ty 

Notes: Etherpad 



Time:
1:00 - 2:00pm ET

Location:
Remotely: Zoom 

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

UIO+ published and searchable on the Chrome Web Store

[Justin Obara]

UIO+ 

 is now publicly published on the Google Chrome Web Store. In the past we 
published the beta versions to the Chrome Web Store but they were unlisted and 
required a direct link to access. As of today, it is now publicly published and 
searchable on the Chrome Web Store. UIO+ is available to install in Chrome and 
other browsers that support installs from the Chrome Web Store, such as the 
latest version of MS Edge. If you run into any issues or have suggestions for 
improvements please file a ticket in the issue tracker 
.

User Interface Options Plus (UIO+) allows you to customize websites to match 
your own personal needs and preferences. Settings for the adaptations can be 
set via the UIO+ adjuster panel.

The following adaptations are supported:

• Character Space
• Contrast
• Enhance Inputs
• Line Space
• Reading Mode
• Right-Click to Select
• Selection Highlight
• Syllables
• Table of Contents
• Text-to-Speech (only for selected text)
• Word Space
• Zoom
Note: The ability to apply an adaptation will vary from page to page

UI Options Plus is the result of a joint effort of the Inclusive Design 
Research Centre at OCAD University and the Trace R&D Center at University of 
Maryland under funding for the FLOE Project from the William and Flora Hewlett 
Foundation and the National Institute on Disability, Independent Living, and 
Rehabilitation Research (NIDILRR), Administration for Community Living under 
grant #90RE5027.

Thanks
Justin


___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Storytelling tool: decoupling editing and viewing stories

[Justin Obara]

Hi Cindy,

Thanks for your feedback on this, and you definitely raise some good points. 

I wasn’t aware that auto save was happening on the server. I had thought it 
would be in the user’s local storage. In that case though, I think it would 
only be published changes that triggered the redeploy. 

Regarding the redeploy, I wonder if we can update the deployed site with only 
the changes, so that the entire site doesn’t have to be rebuilt. However, we 
should be able to debounce the site redeploy, so that multiple incoming changes 
will be packaged together. In general, we’ll probably want some mechanism for 
telling the storytelling tool that the publishing has actually completed and 
that the story is available to view. Not sure how difficult all that will be.

We could also look at ways of having editable sites be dynamic and readonly 
sites be static. However, it might be harder to maintain like that. I’m not 
sure.

Cindy, could you explain a bit about the workflow for the WeCount site? That 
might give us some more ideas about how a potential setup might look and also 
some issues we may run into.

Thanks
Justin

> On Aug 5, 2020, at 1:34 PM, Cindy Li  wrote:
> 
> Hi Justin,
> 
> I think using static websites for archived storytelling websites is a great 
> idea.
> 
> However, for the site that editing can be enabled, since each save to the 
> database will trigger a re-deploy of the static site, we might like to 
> understand and clarify some questions before making a decision:
> 
> 1. The usage of the editing tool: how are stories created? Are they usually 
> created in workshops with a number of people editing/creating stories 
> simultaneously, or the usage is spread over time?
> 2. How fast the static viewing part can be deployed?
> 3. Would swamped saves to the database mess up the deploy of the static part?
> 
> Moreover, with the implementation of server side auto save 
> <https://issues.fluidproject.org/browse/SJRK-289> for uploaded medias/files, 
> creating/editing a story could lead to multiple saves to the database rather 
> than at the publish step.
> 
> Cindy
> 
>> On Aug 5, 2020, at 7:58 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Hi Gregor and Dana,
>> 
>> I was reading over the Branches 
>> <https://github.com/fluid-project/sjrk-story-telling/blob/master/docs/BRANCHES.md>
>>  doc for Storytelling this morning and also reflecting on the testing work 
>> that was needed following the 0.3.0 release last week. If I’m understanding 
>> things correctly, only the AIHEC <https://aihec.inclusivedesign.ca/> 
>> (currently in production use) and staging 
>> <https://staging-stories.floeproject.org/> sites allow for authoring 
>> stories. During the “Storytelling Tool long-term technical road map 
>> discussion 
>> <https://docs.google.com/document/d/1Y7nXxUeCt9qcLQbjYoblzsrKLKpeLA2H6kFyu-EsIl4/edit#heading=h.wn80pjfkqwr2>”
>>  we spoke about the possibility of integrating with a SSG like 11ty 
>> <https://www.11ty.dev/>. I don’t think I fully grasped, and may still not, 
>> the distinction between the authoring of stories and viewing stories on the 
>> site. At the moment it appears that these are coupled together into a single 
>> system which can be set to enable story authoring/editing. In the case where 
>> editing is disabled there is still a server and database backing the 
>> browsing/viewing of stories.
>> 
>> If our end goal is to decouple the authoring/editing from the story 
>> viewing/browsing, we should revisit this along with the login and 
>> authentication. It will probably depend on how things are actually 
>> implemented so I’ll just illustrate one possible scenario below. We should 
>> consider how we actually want this to work, what the benefits and tradeoffs 
>> are, and etc.
>> 
>> Possibile scenario:
>> 
>> The deployed story site is always a static site. When a story is 
>> authored/edited, the server triggers the site to redeploy at which point the 
>> static site is regenerated with the content stored in the database. When 
>> story authoring/editing is enabled, an instance of the storytelling tool is 
>> deployed alongside it. The storytelling tool being just an authoring 
>> interface which stores stories to the database. When login/authentication is 
>> provided, it will also provide a view into the users' stories for 
>> editing/deleting. When story authoring/editing is disabled we only deploy 
>> the static site; the storytelling tool does not need to be deployed. 
>> Additionally the backend database can be archived and disabled if the 
>> stories are intended for view

Re: Storytelling tool: decoupling editing and viewing stories

[Justin Obara]

Hi Gregor and Dana,

Sorry, I had meant to CC you on the e-mail below.

Thanks
Justin

> On Aug 5, 2020, at 7:58 AM, Justin Obara  wrote:
> 
> Hi Gregor and Dana,
> 
> I was reading over the Branches 
> <https://github.com/fluid-project/sjrk-story-telling/blob/master/docs/BRANCHES.md>
>  doc for Storytelling this morning and also reflecting on the testing work 
> that was needed following the 0.3.0 release last week. If I’m understanding 
> things correctly, only the AIHEC <https://aihec.inclusivedesign.ca/> 
> (currently in production use) and staging 
> <https://staging-stories.floeproject.org/> sites allow for authoring stories. 
> During the “Storytelling Tool long-term technical road map discussion 
> <https://docs.google.com/document/d/1Y7nXxUeCt9qcLQbjYoblzsrKLKpeLA2H6kFyu-EsIl4/edit#heading=h.wn80pjfkqwr2>”
>  we spoke about the possibility of integrating with a SSG like 11ty 
> <https://www.11ty.dev/>. I don’t think I fully grasped, and may still not, 
> the distinction between the authoring of stories and viewing stories on the 
> site. At the moment it appears that these are coupled together into a single 
> system which can be set to enable story authoring/editing. In the case where 
> editing is disabled there is still a server and database backing the 
> browsing/viewing of stories.
> 
> If our end goal is to decouple the authoring/editing from the story 
> viewing/browsing, we should revisit this along with the login and 
> authentication. It will probably depend on how things are actually 
> implemented so I’ll just illustrate one possible scenario below. We should 
> consider how we actually want this to work, what the benefits and tradeoffs 
> are, and etc.
> 
> Possibile scenario:
> 
> The deployed story site is always a static site. When a story is 
> authored/edited, the server triggers the site to redeploy at which point the 
> static site is regenerated with the content stored in the database. When 
> story authoring/editing is enabled, an instance of the storytelling tool is 
> deployed alongside it. The storytelling tool being just an authoring 
> interface which stores stories to the database. When login/authentication is 
> provided, it will also provide a view into the users' stories for 
> editing/deleting. When story authoring/editing is disabled we only deploy the 
> static site; the storytelling tool does not need to be deployed. Additionally 
> the backend database can be archived and disabled if the stories are intended 
> for view only and are effectively archived.
> 
> Points of configuration between the systems would include configuration for 
> the SSG to enable/disable the link to the storytelling tool, linking from the 
> storytelling tool to the published story on the static site, and styling for 
> preview in the storytelling tool to match the output in the static site. 
> 
> Please let me know what you think and if I’m misunderstanding anything.
> 
> Thanks
> Justin
> 

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Storytelling tool: decoupling editing and viewing stories

[Justin Obara]

Hi Gregor and Dana,

I was reading over the Branches 

 doc for Storytelling this morning and also reflecting on the testing work that 
was needed following the 0.3.0 release last week. If I’m understanding things 
correctly, only the AIHEC  (currently in 
production use) and staging  sites 
allow for authoring stories. During the “Storytelling Tool long-term technical 
road map discussion 
”
 we spoke about the possibility of integrating with a SSG like 11ty 
. I don’t think I fully grasped, and may still not, the 
distinction between the authoring of stories and viewing stories on the site. 
At the moment it appears that these are coupled together into a single system 
which can be set to enable story authoring/editing. In the case where editing 
is disabled there is still a server and database backing the browsing/viewing 
of stories.

If our end goal is to decouple the authoring/editing from the story 
viewing/browsing, we should revisit this along with the login and 
authentication. It will probably depend on how things are actually implemented 
so I’ll just illustrate one possible scenario below. We should consider how we 
actually want this to work, what the benefits and tradeoffs are, and etc.

Possibile scenario:

The deployed story site is always a static site. When a story is 
authored/edited, the server triggers the site to redeploy at which point the 
static site is regenerated with the content stored in the database. When story 
authoring/editing is enabled, an instance of the storytelling tool is deployed 
alongside it. The storytelling tool being just an authoring interface which 
stores stories to the database. When login/authentication is provided, it will 
also provide a view into the users' stories for editing/deleting. When story 
authoring/editing is disabled we only deploy the static site; the storytelling 
tool does not need to be deployed. Additionally the backend database can be 
archived and disabled if the stories are intended for view only and are 
effectively archived.

Points of configuration between the systems would include configuration for the 
SSG to enable/disable the link to the storytelling tool, linking from the 
storytelling tool to the published story on the static site, and styling for 
preview in the storytelling tool to match the output in the static site. 

Please let me know what you think and if I’m misunderstanding anything.

Thanks
Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Issue tracking

[Justin Obara]

Hi Tony,

Thanks for the feedback. Personally I find that it can be confusing, at least 
in the context of Infusion, because we have JIRA components related to Infusion 
components that are included in an Infusion release and others that aren’t 
(e.g. website). That makes using JIRA’s versioning semantics confusing, and 
means that you can’t use the version semantics for the components that do not 
share the same release as Infusion.

Sorry that paragraph in itself is confusing, but hopefully you understand what 
I mean.

We’ve have also created more JIRA projects 
<https://issues.fluidproject.org/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all>,
 although those also tend to correspond to actual projects we are working on 
and not so much with independent repos. Although sometimes that’s the case.

I find that tracking the issues alongside the code is easier for those joining 
the community and just making use of a repo. It also allows for versioning, 
milestones and etc to be specific to the code base being released/developed. 

I’m curious to hear more of your thoughts, especially because you’ve used both 
systems. Also please let me know if there are workarounds or workflows to 
address the issues I’ve mentioned about JIRA.

Thanks
Justin


> On Jul 6, 2020, at 8:52 AM, Tony Atkins  wrote:
> 
> Hi, Justin.
> 
> When working on the GPII JIRA instance I simply set up a component for each 
> repository and tracked things in the main GPII project.  We might do 
> something similar, handle them as components within the FLUID project on 
> issues.fluidproject.org <http://issues.fluidproject.org/>.  Particularly for 
> the plugins used in linting/testing Infusion itself, it would make linking 
> easier, especially since we also get issue/PR linking via JIRA's DVCS plugin.
> 
> That being said, I do use GH issues for other work, and am not opposed to it 
> in general.
> 
> Cheers,
> 
> 
> Tony
> 
> On Mon, 6 Jul 2020 at 14:35, Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> I’ve added the recently migrated repos to the Google Sheet 
> <https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>.
>  I assume that at least some of these were being tracked in the GPII Jira 
> <https://issues.gpii.net/secure/Dashboard.jspa> instance. It might make sense 
> to migrate these over to GitHub Issues, and if so could be a good place to 
> start looking into that process. 
> 
> Please let me know what you think.
> 
> Thanks
> Justin
> 
>> On Jun 4, 2020, at 9:20 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Hi Everyone,
>> 
>> I haven’t heard any opposing views to my proposal below. I’m taking silence 
>> as consent and have moved forward with the first phase, which is to 
>> catalogue the issue tracking for the public repos in the fluid-project 
>> <https://github.com/fluid-project> and inclusive-design 
>> <https://github.com/inclusive-design> GitHub orgs.
>> 
>> I’ve created a Google Sheet 
>> <https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>
>>  which includes a list of the repos and mentions the Issue Tracker(s) that 
>> are currently being used. Please review and leave comments about the repos. 
>> Pay particular attention to any that you are working on now, have worked on 
>> in the past, or will be working on in the future. Also please provide 
>> feedback on the need for repos. There are many cases where it appears the 
>> repo can be archived or completely removed. And there are many repos where 
>> it isn’t clear what they are used for. Please make sure to fill out the 
>> descriptions in the repos appropriately.
>> 
>> Notes on the Google Sheet: 
>> 
>> Archived Repos: I have highlighted the row and indicated “TRUE” in the 
>> “Archive” column. For these archived repos, we do not need to do anything, 
>> as there is no active work.
>> If there is no “Current Issue Tracker(s)” listed, that means I was not able 
>> to find evidence of any issues filed against that repo based on commits. 
>> There may be an active GitHub Issue tracker, however no Issues have been 
>> filed.
>> 
>> Thanks
>> Justin
>> 
>>> On Feb 24, 2020, at 9:23 AM, Justin Obara >> <mailto:obara.jus...@gmail.com>> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> This topic was touched upon in a recent "Enabling Github Issues for 
>>> Infusion project 
>>> <http://fluid.2324889.n4.nabble.com/Enabling-Github-Issues-for-Infusion-project-td10666.html>”
>>

Re: Issue tracking

[Justin Obara]

I’ve added the recently migrated repos to the Google Sheet 
<https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>.
 I assume that at least some of these were being tracked in the GPII Jira 
<https://issues.gpii.net/secure/Dashboard.jspa> instance. It might make sense 
to migrate these over to GitHub Issues, and if so could be a good place to 
start looking into that process. 

Please let me know what you think.

Thanks
Justin

> On Jun 4, 2020, at 9:20 AM, Justin Obara  wrote:
> 
> Hi Everyone,
> 
> I haven’t heard any opposing views to my proposal below. I’m taking silence 
> as consent and have moved forward with the first phase, which is to catalogue 
> the issue tracking for the public repos in the fluid-project 
> <https://github.com/fluid-project> and inclusive-design 
> <https://github.com/inclusive-design> GitHub orgs.
> 
> I’ve created a Google Sheet 
> <https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>
>  which includes a list of the repos and mentions the Issue Tracker(s) that 
> are currently being used. Please review and leave comments about the repos. 
> Pay particular attention to any that you are working on now, have worked on 
> in the past, or will be working on in the future. Also please provide 
> feedback on the need for repos. There are many cases where it appears the 
> repo can be archived or completely removed. And there are many repos where it 
> isn’t clear what they are used for. Please make sure to fill out the 
> descriptions in the repos appropriately.
> 
> Notes on the Google Sheet: 
> 
> Archived Repos: I have highlighted the row and indicated “TRUE” in the 
> “Archive” column. For these archived repos, we do not need to do anything, as 
> there is no active work.
> If there is no “Current Issue Tracker(s)” listed, that means I was not able 
> to find evidence of any issues filed against that repo based on commits. 
> There may be an active GitHub Issue tracker, however no Issues have been 
> filed.
> 
> Thanks
> Justin
> 
>> On Feb 24, 2020, at 9:23 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Hi Everyone,
>> 
>> This topic was touched upon in a recent "Enabling Github Issues for Infusion 
>> project 
>> <http://fluid.2324889.n4.nabble.com/Enabling-Github-Issues-for-Infusion-project-td10666.html>”
>>  Fluid-Work mailing-list thread. However, what I’m proposing here is 
>> slightly different from that particular discussion so thought it best to 
>> move off into a new thread.
>> 
>> TL;DR: Use GitHub issues for repos that don’t have their own JIRA space
>> 
>> The problem:
>> 
>> A couple of things that I personal find confusing and/or have seen others 
>> trip over are: 
>> That a repo has GitHub issues active and is also tracked in JIRA (e.g. the 
>> floe project website - GitHub Issues 
>> <https://github.com/fluid-project/floeproject.org>, JIRA 
>> <https://issues.fluidproject.org/issues/?jql=project%20=%20FLOE%20AND%20component%20=%20%22FLOE%20Website%22>)
>> That a project/repo is tracked in a JIRA space but doesn’t follow the same 
>> release and versioning. (e.g. fluid-publish 
>> <https://issues.fluidproject.org/issues/?jql=project%20=%20FLUID%20AND%20component%20=%20fluid-publish>)
>> 
>> Proposal:
>> 
>> Use Fluid JIRA project only for Infusion. Move other repos/projects to other 
>> JIRA projects or GitHub issues as needed
>> When migrating issues from between JIRA spaces or GitHub issues, the 
>> existing issues should be migrated as well
>> Use GitHub Issues for existing repos that do not have a corresponding JIRA 
>> project
>> Use GitHub Issues for new repos, unless/until there are features and etc 
>> needed that aren’t supported by GitHub issues but are available in JIRA, at 
>> which point a new JIRA project should be created.
>> For projects/repos that use JIRA, GitHub issues should be disabled and 
>> information provided in the README and/or other appropriate location to 
>> indicate that issues are tracked in JIRA.
>> 
>> The previous thread also discussed having JIRA and GitHub issues synced 
>> together, or migrating everything to GitHub Issues from JIRA. I’m not 
>> intending to weigh in on those questions with this proposal. I’m taking this 
>> from the point of view of how things are currently being done. If one or 
>> more of those other suggestions/proposals are accepted, my suggestions above 
>> can be modified as needed. In general I want to reduce the confusion that 
>> may be happening in our issue trackers at the moment.
>> 
>> Thanks
>> Justin
>> 
>> 
> 

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: GitHub Actions

[Justin Obara]

Hi all,

I just wanted to expand on Gio’s point about secrets, as it prevents/limits 
some integrations with Pull Requests (PRs) from forks. For example, you need a 
secret for the action to comment on a PR, so this type of action would not be 
possible with a PR from a fork. The GITHUB_TOKEN 

 is available to PRs from forks; however, access is read only. 

For clarification, a PR from a fork is how we typically work in our community. 
We have a project repository that contains the canonical source. A contributor 
will fork this repo to their own GitHub space, create a branch from their fork 
to make the changes, and submit a Pull Request back to the project’s 
repository. Because the source, for these PRs, doesn’t reside in the project 
repository, for security purposes they won’t have access to the secrets. Which 
is reasonable to prevent logging or distributing the secret just by submitting 
a PR (if the GitHub Action is modified in the PR). Or causing other project 
wide issues like modifications that the GITHUB_TOKEN might provide if write 
access was available.

I’m actually running into this right now as I’m looking at adding Lighthouse CI 
integration 
 
into the WeCount  site. The Lighthouse 
GitHub Action will communicate with the Lighthouse GitHub App 
 to add status checks for the results, 
but requires a secret to do so. So we’re not able to make use of this feature 
for our PRs.

See: 
https://github.community/t/github-actions-are-severely-limited-on-prs/18179 


It doesn’t look like this has affected any of our current transitions. However, 
it’s worth being aware of for setting up your own GitHub Actions jobs. Some 
work arounds I’ve seen suggested:

Expose the secret as plain text ( I wouldn’t suggest doing this )
Possibly mediate through a GitHub App, or move that action to a GitHub App. For 
example the Netlify GitHub App  handles 
deploying the PRs.

Thanks
Justin

> On Jun 20, 2020, at 10:40 AM, Giovanni Tirloni  wrote:
> 
> It runs automatically, there's no authorization required.
> 
> This would be a problem with Jenkins runners because that meant arbitrary 
> code could be executed on our infrastructure.
> 
> It's less of a problem with GitHub Actions because the CI jobs run on 
> GitHub-owned runners (so they deal with any abuse, not us) and PRs from other 
> repositories do not have access to the secrets stored in our repositories 
> (i.e. even if a PR were to trigger a deploy job, it wouldn't have access to, 
> say, the SSH private key or some other token required for that).
> 
> From: Antranig Basman 
> Sent: Saturday, June 20, 2020 05:47
> To: fluid-work@lists.idrc.ocad.ca ; Giovanni 
> Tirloni 
> Subject: Re: GitHub Actions
>  
> Cheers, this is brilliant work and great to reduce our dependence on 
> Jenkins. Does the CI job run automatically for every update to a PR, or 
> is there some equivalent of the old "ok to test" system?
> 
> On 19/06/2020 13:31, Giovanni Tirloni wrote:
> > Hi Tony,
> > 
> > I translated the Jenkins configuration that lived in the ci-service 
> > repository:
> > 
> > https://github.com/fluid-project/ci-service/blob/master/jenkins_jobs/infusion-pull-request.yml
> >  
> > 
> > 
> > Into the GitHub Actions workflow configuration that lives in each code 
> > repository:
> > 
> > https://github.com/fluid-project/infusion/blob/master/.github/workflows/main.yml
> >  
> > 
> > 
> > Instead of using our Jenkins node (located in the IDRC datacenter), it's 
> > using the GitHub-hosted runners.
> > 
> > 
> > 
> > Here we say the workflow should run on pushes and PRs for the master 
> > branch only:
> > 
> > on: push: branches: [ master ] pull_request: branches: [ master ]
> > 
> > 
> > 
> > The CI job runs on ubuntu-latest (for now, there's a PR to run it on 
> > Windows as well):
> > 
> > jobs: build: runs-on: ubuntu-latest
> > 
> > 
> > The build strategy means GitHub will template/duplicate the build 
> > definition for each of these values. They are just strings but it means 
> > we're testing against Node.js 10.x and 12.x:
> > 
> > strategy: matrix: node-version: [10.x, 12.x]
> > 
> > 
> > 
> > We pass the HEADLESS env var so our tests run in Firefox/Chrome headless:
> > 
> > env: HEADLESS: true
> > 
> > 
> > Then come the actual build instructions. We first do a Git checkout of 
> > the repo:
> > 
> > 
> > steps: - uses: actions/checkout@v2
> > 
> > 
> > 
> > 
> > Then we install the Nod

Re: Archived repositories and the living infrastructure

[Justin Obara]

Hi everyone,

Slight update. We decided to pull in the prefsEditors from the GPII org. It is 
now located at https://github.com/fluid-project/prefs-editors-prototypes 
<https://github.com/fluid-project/prefs-editors-prototypes> and has bee 
unarchived for the purpose of supporting deployment.

Thanks
Justin

> On Jun 16, 2020, at 9:28 AM, Justin Obara  wrote:
> 
> Hi Gio,
> 
> Thanks for the info.
> 
> I’ve unarchived https://github.com/fluid-project/videoPlayer 
> <https://github.com/fluid-project/videoPlayer>; however, 
> https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors> 
> is not part of our GitHub organization. Instead I’ve forked it to 
> https://github.com/fluid-project/prefsEditors 
> <https://github.com/fluid-project/prefsEditors> and you can deploy from there 
> instead. In the future we may want to drop our fork and just maintain the 
> deployments from the GPII GitHub org.
> 
> Thanks
> Justin
> 
>> On Jun 11, 2020, at 9:42 AM, Giovanni Tirloni > <mailto:gtirl...@ocadu.ca>> wrote:
>> 
>> Hi Justin,
>> 
>> Today, the build site is built by 8 different CI/CD jobs 
>> <https://github.com/fluid-project/ci-service/tree/master/jenkins_jobs> that 
>> pull data from various repositories and builds them (or not) in different 
>> ways. That information is not linked in any way to the repositories since 
>> the build instructions live in the ci-service repository.
>> 
>> I'm trying to make each repository self-sufficient so it knows how to build 
>> and serve itself in a minimal/standardized way. The first step is to add the 
>> Dockerfile that codifies the build instructions. The next step is to hook 
>> this into GitHub Actions so it's built and deployed automatically.
>> 
>> From there, developers are free to modify and deploy new versions, as 
>> necessary. Change the build instructions, if needed. They don't need to 
>> learn about a new repository with different conventions, maybe custom 
>> scripts, gotchas, etc.
>> 
>> For repositories that are archived and don't need to be built ever again 
>> (just served forever), the build site creates some challenges to implement 
>> that approach. We can either fully enabled CI/CD for them or not enable it 
>> at all (thus my suggestion to copy the built static content into the 
>> build.fluidproject.org <http://build.fluidproject.org/>repository -- maybe 
>> in an archived directory of sorts).
>> 
>> Thanks,
>> Gio
>> 
>> From: Justin Obara mailto:obara.jus...@gmail.com>>
>> Sent: Thursday, June 11, 2020 08:58
>> To: Giovanni Tirloni mailto:gtirl...@ocadu.ca>>
>> Cc: fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@lists.idrc.ocad.ca> 
>> mailto:fluid-work@lists.idrc.ocad.ca>>
>> Subject: Re: Archived repositories and the living infrastructure
>>  
>> Hi Gio,
>> 
>> I don’t know the full details of what’s needed, but it sounds like the first 
>> option would be the easiest approach. However, we’d need to update the 
>> description to indicate that it is still not in active development and that 
>> it’s just to support the deployment needs.
>> 
>> Regarding your second option, would it be possible to have another repo, 
>> which I guess could be the build site, that, as part of it’s CI/CD process, 
>> did a checkout of the archived repos that need to be deployed? In that way 
>> we can still track the code for the archived repos in their own locations.
>> 
>> Thanks
>> Justin
>> 
>>> On Jun 10, 2020, at 8:22 PM, Giovanni Tirloni >> <mailto:gtirl...@ocadu.ca>> wrote:
>>> 
>>> Hello,
>>> 
>>> Our infrastructure is evolving and one of the main goals is to run all our 
>>> applications on containers. For that, the apps/websites need to be 
>>> "containerized", that is, they must have a Dockerfile and a published image.
>>> 
>>> While working on containerizing some of our apps, I encountered a few 
>>> repositories that are archived (read-only):
>>> 
>>> https://github.com/fluid-project/videoPlayer 
>>> <https://github.com/fluid-project/videoPlayer>
>>> https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors>
>>> 
>>> Although they are archived, they are still served publicly at 
>>> https://build.fluidproject.org <https://build.fluidproject.org/> as 
>>> separate modules/paths.
>>> 
>>> That creates a dilemma for me because I need to properly i

Re: Archived repositories and the living infrastructure

[Justin Obara]

Hi Gio,

Thanks for the info.

I’ve unarchived https://github.com/fluid-project/videoPlayer 
<https://github.com/fluid-project/videoPlayer>; however, 
https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors> is 
not part of our GitHub organization. Instead I’ve forked it to 
https://github.com/fluid-project/prefsEditors 
<https://github.com/fluid-project/prefsEditors> and you can deploy from there 
instead. In the future we may want to drop our fork and just maintain the 
deployments from the GPII GitHub org.

Thanks
Justin

> On Jun 11, 2020, at 9:42 AM, Giovanni Tirloni  wrote:
> 
> Hi Justin,
> 
> Today, the build site is built by 8 different CI/CD jobs 
> <https://github.com/fluid-project/ci-service/tree/master/jenkins_jobs> that 
> pull data from various repositories and builds them (or not) in different 
> ways. That information is not linked in any way to the repositories since the 
> build instructions live in the ci-service repository.
> 
> I'm trying to make each repository self-sufficient so it knows how to build 
> and serve itself in a minimal/standardized way. The first step is to add the 
> Dockerfile that codifies the build instructions. The next step is to hook 
> this into GitHub Actions so it's built and deployed automatically.
> 
> From there, developers are free to modify and deploy new versions, as 
> necessary. Change the build instructions, if needed. They don't need to learn 
> about a new repository with different conventions, maybe custom scripts, 
> gotchas, etc.
> 
> For repositories that are archived and don't need to be built ever again 
> (just served forever), the build site creates some challenges to implement 
> that approach. We can either fully enabled CI/CD for them or not enable it at 
> all (thus my suggestion to copy the built static content into the 
> build.fluidproject.org <http://build.fluidproject.org/>repository -- maybe in 
> an archived directory of sorts).
> 
> Thanks,
> Gio
> 
> From: Justin Obara 
> Sent: Thursday, June 11, 2020 08:58
> To: Giovanni Tirloni 
> Cc: fluid-work@lists.idrc.ocad.ca 
> Subject: Re: Archived repositories and the living infrastructure
>  
> Hi Gio,
> 
> I don’t know the full details of what’s needed, but it sounds like the first 
> option would be the easiest approach. However, we’d need to update the 
> description to indicate that it is still not in active development and that 
> it’s just to support the deployment needs.
> 
> Regarding your second option, would it be possible to have another repo, 
> which I guess could be the build site, that, as part of it’s CI/CD process, 
> did a checkout of the archived repos that need to be deployed? In that way we 
> can still track the code for the archived repos in their own locations.
> 
> Thanks
> Justin
> 
>> On Jun 10, 2020, at 8:22 PM, Giovanni Tirloni > <mailto:gtirl...@ocadu.ca>> wrote:
>> 
>> Hello,
>> 
>> Our infrastructure is evolving and one of the main goals is to run all our 
>> applications on containers. For that, the apps/websites need to be 
>> "containerized", that is, they must have a Dockerfile and a published image.
>> 
>> While working on containerizing some of our apps, I encountered a few 
>> repositories that are archived (read-only):
>> 
>> https://github.com/fluid-project/videoPlayer 
>> <https://github.com/fluid-project/videoPlayer>
>> https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors>
>> 
>> Although they are archived, they are still served publicly at 
>> https://build.fluidproject.org <https://build.fluidproject.org/> as separate 
>> modules/paths.
>> 
>> That creates a dilemma for me because I need to properly integrate them into 
>> a CI/CD workflow. They will likely require more changes as new Docker images 
>> are released and they need to be updated for security fixes, etc. In other 
>> words, no more work is planned on these projects but they are still very 
>> much alive in the infrastructure.
>> 
>> I see two paths forward:
>> They are unarchived so I can submit PRs to have the Dockerfile added (and 
>> future changes).
>> They are copied into the build.fluidproject.org 
>> <http://build.fluidproject.org/> and served as static content from there
>> Any thoughts?
>> 
>> Regards,
>> Giovanni Tirloni
>> DevOps Engineer
>> Inclusive Design Research Centre, OCAD University
>> https://idrc.ocadu.ca 
>> <https://idrc.ocadu.ca/>___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> <mailto:fluid-work@lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Lighting Workshop - Laser Eye Checklist: Duplication

[Justin Obara]

Hi Everyone,

Thanks for joining and participating. Please do update the Google Sheet 
<https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit?usp=sharing>
 with any more updates/revisions/changes as needed. And also, if you have 
looked at the example, feel free to share back your revised versions. I’ve 
decided to leave it in my GitHub space for now, but will move if others decide 
to use it in the future.

Thanks
Justin

> On Jun 11, 2020, at 9:09 AM, Justin Obara  wrote:
> 
> Hi Everyone,
> 
> Today will be our first Lightning Workshop, which will take place immediately 
> following the standup call in the same zoom room 
> <https://ocadu.zoom.us/j/727986784>. Initially we’ll be going through the 
> items in the Laser Eye Checklist 
> <https://wiki.fluidproject.org/display/fluid/Laser+Eye+Checklist>, with the 
> first topic covering Duplication.
> 
> To prepare for the first workshop I’ve created an Google Sheet 
> <https://docs.google.com/document/d/1AS1RsbSls5XfTxAbxAGRSCh7LgUuRVI0aNYsMngVb7g/edit?usp=sharing>
>  for notes and some simple example code 
> <https://github.com/jobara/laser-eye-checklist-examples/blob/master/examples/duplication/index.html>
>  that’s full of duplications. Please look over the example code and think 
> about issues there and how to improve it. You can even fork the repo and 
> experiment with how to refactor the code. During the workshop we can talk 
> over the points and hopefully come up with an improved version to post along 
> side the example.
> 
> I might try to do some collaborative editing via Visual Studio Code live 
> share. Please be prepared to join in with code sharing if we have time for it.
> 
> Thanks
> Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Archived repositories and the living infrastructure

[Justin Obara]

Hi Michelle,

That’s a good point and something I’ve been pondering as well. A couple 
thoughts I’ve had:

Should it be integrated more closely with the IDRC or Fluid Project site? 
How can we more easily maintain links for demos, examples, and tests from 
Infusion? These links often fall out of date, and we’re probably missing a 
bunch from the build site right now.

I still actually use the build site for testing and comparing to my in progress 
work. It’s also useful for pointing out examples of our work. I suppose we 
don’t specifically need the build site for those, but something that will allow 
us to capture those requirements. Maybe each repo has their own build 
site/deployment, and we have links from the repos and project pages to those 
builds.

Regarding links to funders. Those that come from a build of infusion and point 
at the demos directory can’t be counted on as reliable or stable. We will from 
time-to-time rename, move, add, remove and etc those demos. Also they point at 
the latest version from master, so things included in reports may be quite 
different when someone follows the link potentially years later.

Thanks
Justin

> On Jun 11, 2020, at 8:37 AM, Michelle D'Souza  wrote:
> 
> I wonder if it’s also time for us to consider how/if we use 
> build.fluidproject.org <http://build.fluidproject.org/>. I’m pretty sure 
> links to it have been in reports and sent to funders, but I don’t think we’ve 
> updated the site in quite a while. Thoughts? Does anyone use it? Should we 
> use? For what?
> 
> Thanks,
> 
> Michelle
> 
> 
> 
>> On Jun 11, 2020, at 7:58 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> 
>> Hi Gio,
>> 
>> I don’t know the full details of what’s needed, but it sounds like the first 
>> option would be the easiest approach. However, we’d need to update the 
>> description to indicate that it is still not in active development and that 
>> it’s just to support the deployment needs.
>> 
>> Regarding your second option, would it be possible to have another repo, 
>> which I guess could be the build site, that, as part of it’s CI/CD process, 
>> did a checkout of the archived repos that need to be deployed? In that way 
>> we can still track the code for the archived repos in their own locations.
>> 
>> Thanks
>> Justin
>> 
>>> On Jun 10, 2020, at 8:22 PM, Giovanni Tirloni >> <mailto:gtirl...@ocadu.ca>> wrote:
>>> 
>>> Hello,
>>> 
>>> Our infrastructure is evolving and one of the main goals is to run all our 
>>> applications on containers. For that, the apps/websites need to be 
>>> "containerized", that is, they must have a Dockerfile and a published image.
>>> 
>>> While working on containerizing some of our apps, I encountered a few 
>>> repositories that are archived (read-only):
>>> 
>>> https://github.com/fluid-project/videoPlayer 
>>> <https://github.com/fluid-project/videoPlayer>
>>> https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors>
>>> 
>>> Although they are archived, they are still served publicly at 
>>> https://build.fluidproject.org <https://build.fluidproject.org/> as 
>>> separate modules/paths.
>>> 
>>> That creates a dilemma for me because I need to properly integrate them 
>>> into a CI/CD workflow. They will likely require more changes as new Docker 
>>> images are released and they need to be updated for security fixes, etc. In 
>>> other words, no more work is planned on these projects but they are still 
>>> very much alive in the infrastructure.
>>> 
>>> I see two paths forward:
>>> They are unarchived so I can submit PRs to have the Dockerfile added (and 
>>> future changes).
>>> They are copied into the build.fluidproject.org 
>>> <http://build.fluidproject.org/> and served as static content from there
>>> Any thoughts?
>>> 
>>> Regards,
>>> Giovanni Tirloni
>>> DevOps Engineer
>>> Inclusive Design Research Centre, OCAD University
>>> https://idrc.ocadu.ca 
>>> <https://idrc.ocadu.ca/>___
>>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>>> <mailto:fluid-work@lists.idrc.ocad.ca>
>>> To unsubscribe, change settings or access archives,
>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
>> ___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> <mailto:fluid-work@lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Lighting Workshop - Laser Eye Checklist: Duplication

[Justin Obara]

Hi Everyone,

Today will be our first Lightning Workshop, which will take place immediately 
following the standup call in the same zoom room 
. Initially we’ll be going through the items 
in the Laser Eye Checklist 
, with the 
first topic covering Duplication.

To prepare for the first workshop I’ve created an Google Sheet 

 for notes and some simple example code 

 that’s full of duplications. Please look over the example code and think about 
issues there and how to improve it. You can even fork the repo and experiment 
with how to refactor the code. During the workshop we can talk over the points 
and hopefully come up with an improved version to post along side the example.

I might try to do some collaborative editing via Visual Studio Code live share. 
Please be prepared to join in with code sharing if we have time for it.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Archived repositories and the living infrastructure

[Justin Obara]

Hi Gio,

I don’t know the full details of what’s needed, but it sounds like the first 
option would be the easiest approach. However, we’d need to update the 
description to indicate that it is still not in active development and that 
it’s just to support the deployment needs.

Regarding your second option, would it be possible to have another repo, which 
I guess could be the build site, that, as part of it’s CI/CD process, did a 
checkout of the archived repos that need to be deployed? In that way we can 
still track the code for the archived repos in their own locations.

Thanks
Justin

> On Jun 10, 2020, at 8:22 PM, Giovanni Tirloni  wrote:
> 
> Hello,
> 
> Our infrastructure is evolving and one of the main goals is to run all our 
> applications on containers. For that, the apps/websites need to be 
> "containerized", that is, they must have a Dockerfile and a published image.
> 
> While working on containerizing some of our apps, I encountered a few 
> repositories that are archived (read-only):
> 
> https://github.com/fluid-project/videoPlayer 
> 
> https://github.com/GPII/prefsEditors 
> 
> Although they are archived, they are still served publicly at 
> https://build.fluidproject.org  as separate 
> modules/paths.
> 
> That creates a dilemma for me because I need to properly integrate them into 
> a CI/CD workflow. They will likely require more changes as new Docker images 
> are released and they need to be updated for security fixes, etc. In other 
> words, no more work is planned on these projects but they are still very much 
> alive in the infrastructure.
> 
> I see two paths forward:
> They are unarchived so I can submit PRs to have the Dockerfile added (and 
> future changes).
> They are copied into the build.fluidproject.org 
>  and served as static content from there
> Any thoughts?
> 
> Regards,
> Giovanni Tirloni
> DevOps Engineer
> Inclusive Design Research Centre, OCAD University
> https://idrc.ocadu.ca 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Privacy Policy

[Justin Obara]

Hi Everyone,

The Fluid Community has been around for a long time, and many of us have been 
part of that community for much of that time. We’ve always operated in an open, 
accessible and inclusive manner. I believe that those in the community know 
that and have participated as such. However, it seemed like the time to 
formalize our policy and better communicate it out.

Please review the Privacy Policy 
 posted on the 
wiki. For those that build and maintain our websites, please add links back to 
it, so that those visiting our sites are aware of it as well.

If you have any comments, questions or concerns. Please feel free to follow up 
here or in an of our other open communication channels 
.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Issue tracking

[Justin Obara]

Hi Everyone,

I haven’t heard any opposing views to my proposal below. I’m taking silence as 
consent and have moved forward with the first phase, which is to catalogue the 
issue tracking for the public repos in the fluid-project 
<https://github.com/fluid-project> and inclusive-design 
<https://github.com/inclusive-design> GitHub orgs.

I’ve created a Google Sheet 
<https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>
 which includes a list of the repos and mentions the Issue Tracker(s) that are 
currently being used. Please review and leave comments about the repos. Pay 
particular attention to any that you are working on now, have worked on in the 
past, or will be working on in the future. Also please provide feedback on the 
need for repos. There are many cases where it appears the repo can be archived 
or completely removed. And there are many repos where it isn’t clear what they 
are used for. Please make sure to fill out the descriptions in the repos 
appropriately.

Notes on the Google Sheet: 

Archived Repos: I have highlighted the row and indicated “TRUE” in the 
“Archive” column. For these archived repos, we do not need to do anything, as 
there is no active work.
If there is no “Current Issue Tracker(s)” listed, that means I was not able to 
find evidence of any issues filed against that repo based on commits. There may 
be an active GitHub Issue tracker, however no Issues have been filed.

Thanks
Justin

> On Feb 24, 2020, at 9:23 AM, Justin Obara  wrote:
> 
> Hi Everyone,
> 
> This topic was touched upon in a recent "Enabling Github Issues for Infusion 
> project 
> <http://fluid.2324889.n4.nabble.com/Enabling-Github-Issues-for-Infusion-project-td10666.html>”
>  Fluid-Work mailing-list thread. However, what I’m proposing here is slightly 
> different from that particular discussion so thought it best to move off into 
> a new thread.
> 
> TL;DR: Use GitHub issues for repos that don’t have their own JIRA space
> 
> The problem:
> 
> A couple of things that I personal find confusing and/or have seen others 
> trip over are: 
> That a repo has GitHub issues active and is also tracked in JIRA (e.g. the 
> floe project website - GitHub Issues 
> <https://github.com/fluid-project/floeproject.org>, JIRA 
> <https://issues.fluidproject.org/issues/?jql=project%20=%20FLOE%20AND%20component%20=%20%22FLOE%20Website%22>)
> That a project/repo is tracked in a JIRA space but doesn’t follow the same 
> release and versioning. (e.g. fluid-publish 
> <https://issues.fluidproject.org/issues/?jql=project%20=%20FLUID%20AND%20component%20=%20fluid-publish>)
> 
> Proposal:
> 
> Use Fluid JIRA project only for Infusion. Move other repos/projects to other 
> JIRA projects or GitHub issues as needed
> When migrating issues from between JIRA spaces or GitHub issues, the existing 
> issues should be migrated as well
> Use GitHub Issues for existing repos that do not have a corresponding JIRA 
> project
> Use GitHub Issues for new repos, unless/until there are features and etc 
> needed that aren’t supported by GitHub issues but are available in JIRA, at 
> which point a new JIRA project should be created.
> For projects/repos that use JIRA, GitHub issues should be disabled and 
> information provided in the README and/or other appropriate location to 
> indicate that issues are tracked in JIRA.
> 
> The previous thread also discussed having JIRA and GitHub issues synced 
> together, or migrating everything to GitHub Issues from JIRA. I’m not 
> intending to weigh in on those questions with this proposal. I’m taking this 
> from the point of view of how things are currently being done. If one or more 
> of those other suggestions/proposals are accepted, my suggestions above can 
> be modified as needed. In general I want to reduce the confusion that may be 
> happening in our issue trackers at the moment.
> 
> Thanks
> Justin
> 
> 

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Short/Lighting Skill development meetings

[Justin Obara]

A while back I had suggested the idea of doing skill building/professional 
development related community meetings. However, with the pandemic and our 
current moratorium on Wednesday afternoon meetings, we’ve more or less put the 
community meetings on hiatus. What I’d like to suggest now is to have some 
brief/lightning skill development meetings in their place.

What I’d like to suggest is that these meetings take place on Tuesdays and 
Thursdays directly following the planning and standup meetings respectively. 
They should last on the order of 10 - 15 minutes and concisely cover a specific 
topic. To start things off, I think we can cover a point of the Laser Eye 
Checklist , 
one item per meeting. This will both serve as a reminder about what we are 
aiming for in terms of our development, but also as an opportunity to expand on 
what each point means, and review the checklist itself. (An additional final 
outcome could be to create a Pull Request Template and check to use with our 
projects on GitHub.)

Please let me know what you think. Also, ideally, we’ll have different people 
covering each topic, so please let me know if you’d like to lead any. Lastly 
we’ll need some more ideas for the future, so feel free to suggest those as 
well.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

PR merging options

[Justin Obara]

Hi everyone,

After our planning meeting yesterday, several of us hung back to talk about PR 
merging options. The original discussion started in the fluid-work IRC channel 
.

I’ve written up the information we gathered in our discussion and put it up on 
the wiki at Git Merge Strategies 
. Please feel 
free to add/amend that page. In general this is to provide some ideas for 
options that projects can use for merging PRs, and is not intended to be 
prescriptive of what method must be used.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( Tuesday May 26 ): Fable

[Justin Obara]

At next week’s Community Meeting 
 ( Tuesday May 
26, 2020 ) Fable  will be joining us to talk 
about their services. Please note the special time and date of this community 
meeting.

Time:
2:00 - 3:00pm ET

Location:
Remotely: Zoom 

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Proposal to remove IE 11 support from Infusion

[Justin Obara]

Thanks for those who have provided feedback. It’s been a couple of weeks and I 
haven’t heard any dissenting points for removing IE 11 support. I think we can 
consider this proposal supported. At this point, we should no longer consider 
that anything beyond the 2.x line of Infusion provides official support for IE 
11.

Thanks
Justin

> On Apr 30, 2020, at 10:54 AM, Justin Obara  wrote:
> 
> Hi Alan,
> 
> Thanks for sharing. In the case of IE 11 it’s a bit confusing, but it appears 
> that it will receive technical support at least through 2023 due to its 
> inclusion in Windows 8. Related to Windows 10 it may depend on if/when they 
> remove it from Windows 10. For LTSB builds of Windows 10, it looks like it 
> will have extended support till at least 2029. However, that support is 
> probably only for security issues.
> 
> Thanks
> Justin
> 
>> On Apr 30, 2020, at 10:40 AM, Alan Harnum > <mailto:ahar...@ocadu.ca>> wrote:
>> 
>> +1 to removing IE11 support. It may also be worth reviewing Microsoft’s own 
>> comments about IE11’s support period: 
>> https://support.microsoft.com/en-ca/help/17454/lifecycle-faq-internet-explorer-and-edge
>>  
>> <https://support.microsoft.com/en-ca/help/17454/lifecycle-faq-internet-explorer-and-edge>
>>  
>> From: fluid-work > <mailto:fluid-work-boun...@lists.idrc.ocad.ca>> On Behalf Of Colin Clark
>> Sent: April 30, 2020 9:31 AM
>> To: Justin Obara mailto:obara.jus...@gmail.com>>
>> Cc: fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@lists.idrc.ocad.ca>
>> Subject: Re: Proposal to remove IE 11 support from Infusion
>>  
>> Hi Justin,
>>  
>> I feel quite strongly that the cost and complexity of maintaining support 
>> for IE 11 strongly outweighs the value of it at this point in time. 
>> Infusion’s mandate is to explore how programming in the future could be a 
>> more inclusive practice if users were able to adapt their software and 
>> continue the design process on their own, without being expert programmers. 
>> That’s a very ambitious goal, and we have a small community—so anything we 
>> can do to simplify the work and focus on this goal seems preferable to me.
>>  
>> Colin
>>  
>> 
>> 
>> On Apr 30, 2020, at 8:44 AM, Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>>  
>> Hi Everyone,
>>  
>> I would like to get community feedback on Infusion no longer supporting IE 
>> 11. The discussion kicked up again after work on FLUID-6488 
>> <https://issues.fluidproject.org/browse/FLUID-6488>; see discussion in 
>> comments. Initially we planned to move off of supporting IE 11 after the 
>> Infusion 3.0 release. We had hoped to have that out in early 2020. However, 
>> due to a variety of factors, including the current pandemic, our work on 
>> Infusion has slowed and the actual 3.0 release date isn’t clear. 
>>  
>> What we’d like to propose now is to immediately stop officially supporting 
>> IE 11. That doesn’t mean we’ll be going through and removing IE 11 specific 
>> code from Infusion right away; although that may happen over time. It does 
>> mean that we’ll no longer test in IE 11 and will no longer guarantee that 
>> Infusion works in IE 11.
>>  
>> In the immediate case this will reduce maintenance and development burdens. 
>> In the long run, and why we always needed to eventually drop support, is 
>> that IE 11 support is preventing us from using more modern JS and CSS 
>> techniques, APIs, and etc. Already we don’t support Text-to-Speech in IE 11 
>> and Proxy 
>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy>
>>  is another features we’d like to use in the framework. (See: FLUID-6372 
>> <https://issues.fluidproject.org/browse/FLUID-6372>).
>>  
>> Depending on the benchmark you look at, IE 11 usage sits around 2-4% (see: 
>> https://en.wikipedia.org/wiki/Usage_share_of_web_browsers 
>> <https://en.wikipedia.org/wiki/Usage_share_of_web_browsers>). As the linked 
>> article mentions the accuracy of these metrics are susceptible to over and 
>> under estimations from a technical perspective. Additionally we know that 
>> there are a variety of other reasons why numbers may not tell the whole 
>> story. With that in mind, I want to also check with those in the community 
>> that use Infusion and get an understanding of your requirements and thoughts 
>> on this in general.
>>  
>> Thanks
>> Justin
>>  
>> ___
>> fluid-work mai

Re: Proposal to remove IE 11 support from Infusion

[Justin Obara]

Hi Alan,

Thanks for sharing. In the case of IE 11 it’s a bit confusing, but it appears 
that it will receive technical support at least through 2023 due to its 
inclusion in Windows 8. Related to Windows 10 it may depend on if/when they 
remove it from Windows 10. For LTSB builds of Windows 10, it looks like it will 
have extended support till at least 2029. However, that support is probably 
only for security issues.

Thanks
Justin

> On Apr 30, 2020, at 10:40 AM, Alan Harnum  wrote:
> 
> +1 to removing IE11 support. It may also be worth reviewing Microsoft’s own 
> comments about IE11’s support period: 
> https://support.microsoft.com/en-ca/help/17454/lifecycle-faq-internet-explorer-and-edge
>  
> <https://support.microsoft.com/en-ca/help/17454/lifecycle-faq-internet-explorer-and-edge>
>  
> From: fluid-work  On Behalf Of Colin 
> Clark
> Sent: April 30, 2020 9:31 AM
> To: Justin Obara 
> Cc: fluid-work@lists.idrc.ocad.ca
> Subject: Re: Proposal to remove IE 11 support from Infusion
>  
> Hi Justin,
>  
> I feel quite strongly that the cost and complexity of maintaining support for 
> IE 11 strongly outweighs the value of it at this point in time. Infusion’s 
> mandate is to explore how programming in the future could be a more inclusive 
> practice if users were able to adapt their software and continue the design 
> process on their own, without being expert programmers. That’s a very 
> ambitious goal, and we have a small community—so anything we can do to 
> simplify the work and focus on this goal seems preferable to me.
>  
> Colin
>  
> 
> 
> On Apr 30, 2020, at 8:44 AM, Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
>  
> Hi Everyone,
>  
> I would like to get community feedback on Infusion no longer supporting IE 
> 11. The discussion kicked up again after work on FLUID-6488 
> <https://issues.fluidproject.org/browse/FLUID-6488>; see discussion in 
> comments. Initially we planned to move off of supporting IE 11 after the 
> Infusion 3.0 release. We had hoped to have that out in early 2020. However, 
> due to a variety of factors, including the current pandemic, our work on 
> Infusion has slowed and the actual 3.0 release date isn’t clear. 
>  
> What we’d like to propose now is to immediately stop officially supporting IE 
> 11. That doesn’t mean we’ll be going through and removing IE 11 specific code 
> from Infusion right away; although that may happen over time. It does mean 
> that we’ll no longer test in IE 11 and will no longer guarantee that Infusion 
> works in IE 11.
>  
> In the immediate case this will reduce maintenance and development burdens. 
> In the long run, and why we always needed to eventually drop support, is that 
> IE 11 support is preventing us from using more modern JS and CSS techniques, 
> APIs, and etc. Already we don’t support Text-to-Speech in IE 11 and Proxy 
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy>
>  is another features we’d like to use in the framework. (See: FLUID-6372 
> <https://issues.fluidproject.org/browse/FLUID-6372>).
>  
> Depending on the benchmark you look at, IE 11 usage sits around 2-4% (see: 
> https://en.wikipedia.org/wiki/Usage_share_of_web_browsers 
> <https://en.wikipedia.org/wiki/Usage_share_of_web_browsers>). As the linked 
> article mentions the accuracy of these metrics are susceptible to over and 
> under estimations from a technical perspective. Additionally we know that 
> there are a variety of other reasons why numbers may not tell the whole 
> story. With that in mind, I want to also check with those in the community 
> that use Infusion and get an understanding of your requirements and thoughts 
> on this in general.
>  
> Thanks
> Justin
>  
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> <mailto:fluid-work@lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
>  
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> <mailto:fluid-work@lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Proposal to remove IE 11 support from Infusion

[Justin Obara]

Hi Everyone,

I would like to get community feedback on Infusion no longer supporting IE 11. 
The discussion kicked up again after work on FLUID-6488 
; see discussion in 
comments. Initially we planned to move off of supporting IE 11 after the 
Infusion 3.0 release. We had hoped to have that out in early 2020. However, due 
to a variety of factors, including the current pandemic, our work on Infusion 
has slowed and the actual 3.0 release date isn’t clear. 

What we’d like to propose now is to immediately stop officially supporting IE 
11. That doesn’t mean we’ll be going through and removing IE 11 specific code 
from Infusion right away; although that may happen over time. It does mean that 
we’ll no longer test in IE 11 and will no longer guarantee that Infusion works 
in IE 11.

In the immediate case this will reduce maintenance and development burdens. In 
the long run, and why we always needed to eventually drop support, is that IE 
11 support is preventing us from using more modern JS and CSS techniques, APIs, 
and etc. Already we don’t support Text-to-Speech in IE 11 and Proxy 

 is another features we’d like to use in the framework. (See: FLUID-6372 
).

Depending on the benchmark you look at, IE 11 usage sits around 2-4% (see: 
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers 
). As the linked 
article mentions the accuracy of these metrics are susceptible to over and 
under estimations from a technical perspective. Additionally we know that there 
are a variety of other reasons why numbers may not tell the whole story. With 
that in mind, I want to also check with those in the community that use 
Infusion and get an understanding of your requirements and thoughts on this in 
general.

Thanks
Justin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: GSOC Proposal

[Justin Obara]

Hi Yash,

Tony Atkins is still the mentor for that project. 

Thanks
Justin

> On Apr 25, 2020, at 6:06 PM, Yash Mathne  wrote:
> 
> Hey, 
> 
> This is with reference to my GSoC proposal for the project "Using a Game 
> Controller as a Navigation Aid". 
> 
> I had been maintaining a constant feedback loop with Mr. Tony Atkins 
> regarding this project and have hence included a proposal with 2 subsections 
> as we had discussed. I have however stopped receiving any communication from 
> him for over a month now and have noticed that some other mentors have been 
> handling the queries for this project on the fluid mailing list as well.
> 
> The reason for the mail is that the dual structure of my proposal might be 
> out of context as my conversations with Mr. Tony have been on his personal 
> email rather than on the mailing list, so in the off chance some other mentor 
> is now handling this project, I wanted to attach the conversation that led to 
> me including the dual structure in my proposal. 
> 
> Thank you and I wish everyone at Fluid and on the mailing list the best of 
> health during these unsure times, 
> Yash Mathne
> 
>  Project.pdf>___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Default community health files for GitHub

[Justin Obara]

Today I’ve added a .github  
repository to the fluid-project  GitHub org. 
At least for now, this has also been forked into the inclusive-design 
 GitHub org. This allows for all of the 
repositories within the org to take on the default community health files 

 if they haven’t already specified their own. This will hopefully make all of 
our repos more consistent and will require less work for setting up new 
repositories. However, each repo should setup their own versions as needed.

In short community health files provide contributors and users of our 
repositories to more easily engage with and join our community.

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Issue GPII - 4381 : Doubts

[Justin Obara]

Hi Yash,

We’re still in the process of discussing designs for it. You’re welcome to 
leave feedback on the Issue if you have ideas you’d like to contribute. I know 
a few GSoC applicants have looked at this issue over the last month or so, 
which may be why it’s marked as in progress. 

Thanks
Justin

> On Apr 14, 2020, at 6:14 AM, Yash Mathne  wrote:
> 
> Hey community members, 
> 
> Was working on this issue when I realized the structure of the extension is 
> quite a bit more complicated than I had anticipated, I have since gathered up 
> the skills to begin working on the same. I would like to ask the community 
> mentors if I can begin working on this issue or is someone else already 
> involved as the status right now is :-  In Progress. 
> 
> Yours Sincerely,
> Yash Mathne
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: A request to discuss my project proposal

[Justin Obara]

Hi Jenniline,

Basically we want the contents of the site to be one repo and the static site 
generator related bits in another. For example it would make switching to a new 
static site generator easier in the future. 

I wasn’t exactly clear on what your question was, but I hope that answers it.

Thanks
Justin

> On Mar 30, 2020, at 12:00 PM, Jenniline Ebai  wrote:
> 
> Hi @Justin Obara <mailto:obara.jus...@gmail.com> ,
> 
> I am a GSOC aspirant I will like to apply for the project "Refactor and 
> Automate Infusion Documentation".   
> I will like to discuss my project proposal with you since you are one of the 
> mentors. 
> I have much interest in the project even though I came late to the 
> organisation. 
> 
> I have knowledge on how my proposal should look like. I have viewed many 
> templates just that I am having a bit of confusion at the level of 
> implementation of the project. 
> 
> I have researched which tool is the best to use and I have concluded on Hugo 
> or Jekyll my proposal will contain that. 
> 
> However at the level of refactoring and automating the Documentation  is 
> where I am a bit confused. 
> 
> I will really appreciate if you help me with a clearer picture of what is 
> expected and an idea of how to go about it. 
> I ask this because I learned that I can discuss my project proposal with a 
> mentor.
> And that students that discuss proposals with their mentors are those that 
> have a better understanding of the project and a solution.
> 
> My own strategy is not yet very detailed and concise. It is one that has the 
> form of rebuilding the Documentation site and automating content using Hugo's 
>  automation method. 
> I know it is not the best that is why I am contacting you.
> 
> 
> Thanks I await your kind reply.
> Jenniline

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Community Meeting ( April 1 ): Problems Machine Learning can Solve

[Justin Obara]

At this week’s Community Meeting 
 ( April 1, 
2020 ) Ted will be talking about Problems Machine Learning can Solve. He’ll be 
providing an overview of the main tasks Machine Learning can perform and a 
shallow dive into how they work in the background.

Time:
2:30 - 4:00pm ET

Location:
Remotely: Zoom 

Thanks
Justin___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Regarding - Migrate FLOE & Fluid project websites & Refactor Doc

[Justin Obara]

Hi Vaibhav,

I guess that’s a fair question. We’ll have to consider it along with the other 
proposals. I suppose you should make sure that your proposal satisfies at least 
one of the project ideas, so that it can be considered with that.

Thanks
Justin

> On Mar 30, 2020, at 8:59 AM, Vaibhav  wrote:
> 
> Hey Justin,
> Thanks for the reply but if I add the combination of both to my proposal and 
> if the combination isn't considered then will my proposal be considered for 
> either of the two options?
> Thanks,
> Vaibhav
> 
> 
> 
> 
> On Mon, Mar 30, 2020 at 6:18 PM Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> Hi Vaibhav,
> 
> Something like that would need to be discussed with the community. You’re 
> welcome to add it to your proposal, but I couldn’t tell you right now if it’s 
> a change that we’d make at this point.
> 
> Thanks
> Justin
> 
>> On Mar 29, 2020, at 7:02 AM, Vaibhav > <mailto:vaibhav1...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I wanted to ask is it possible to combine both of these projects into one 
>> for example, instead of creating a separate website for Fluid project and 
>> Infusion Docs project (which is present on Fluid project website), why don't 
>> we have the docs, blog and other website content on one website. I'm saying 
>> this by keeping Docusaurus into consideration.
>> 
>> Thanks,
>> Vaibhav
>> 
>> 
>> 
>> 
>> ___
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
>> <mailto:fluid-work@lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
>> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Regarding the project "Port UIO+ Chrome Extension to Firefox and Safari"

[Justin Obara]

Hi Umang,

You will need to have tests for the extension. One of the goals of the project 
is to share as much of the code base as possible across the various extensions.

Thanks
Justin

> On Mar 30, 2020, at 9:21 AM, Umang Modi  wrote:
> 
> Hello Justin,
> 
> Thanks for the reply. I'll definately do that and just wanted to clarify that 
> do I have to write the tests for Firefox separately as all the given test 
> files for Chrome is running fine for Firefox browser as well. Please reply 
> soon :)
> 
> Thanks
> Umang
> 
> On Mon, Mar 30, 2020, 6:19 PM Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> Hello Umang,
> 
> You should make sure that the porting of the extension to other browsers will 
> be easily maintainable as new features and bug fixes are added. Also don’t 
> forget to add time for implementing new adaptions to use in the extension.
> 
> Thanks
> Justin
> 
>> On Mar 28, 2020, at 5:15 PM, Umang Modi > <mailto:umangkumarm...@gmail.com>> wrote:
>> 
>> Hi Justin,
>> 
>> I am already halfway through the proposal but have a doubt. 
>> 
>> As I'm seeing in the repository, to port the extension there will be very 
>> less changes in the codebase and almost all the documentation will be same 
>> except for some API code configurations & handling errors while testing and 
>> debugging. So, I assume this will not take much time as most of the task 
>> will include copying and pasting the code.
>> 
>> So just wanted to know if I should set up the entire CI configurations or 
>> just port the extension by the above process?
>> 
>> Regards,
>> Umang Modi
>> 
>> On Thu, Mar 26, 2020, 9:16 PM Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> You should just update your existing PR.
>> 
>>> On Mar 26, 2020, at 11:39 AM, Umang Modi >> <mailto:umangkumarm...@gmail.com>> wrote:
>>> 
>>> I'm really really sorry for this. Shall I make a PR again to the project's 
>>> repo?
>>> 
>>> Thanks,
>>> Umang
>>> 
>>> On Thu, Mar 26, 2020, 9:01 PM Justin Obara >> <mailto:obara.jus...@gmail.com>> wrote:
>>> It looks like you’ve made those PRs against your own repo. You need to make 
>>> the PR against the project’s repo. Also, you shouldn’t make new PRs for 
>>> each commit. Those should all be done in the same branch and submitted 
>>> under a single PR. If the code changes are not related, then they should be 
>>> filed under a separate issue and separate PR.
>>> 
>>> Thanks
>>> Justin
>>> 
>>>> On Mar 26, 2020, at 11:19 AM, Umang Modi >>> <mailto:umangkumarm...@gmail.com>> wrote:
>>>> 
>>>> No, I've updated the previous code and again made a PR today.
>>>> 
>>>> For manifest.json :
>>>> https://github.com/modiumang28/gpii-chrome-extension/pull/1 
>>>> <https://github.com/modiumang28/gpii-chrome-extension/pull/1>
>>>> 
>>>> For background.js :
>>>> https://github.com/modiumang28/gpii-chrome-extension/pull/2 
>>>> <https://github.com/modiumang28/gpii-chrome-extension/pull/2>
>>>> 
>>>> On Thu, Mar 26, 2020, 8:42 PM Justin Obara >>> <mailto:obara.jus...@gmail.com>> wrote:
>>>> I assume you mean https://github.com/GPII/gpii-chrome-extension/pull/49 
>>>> <https://github.com/GPII/gpii-chrome-extension/pull/49>. I reviewed it 2 
>>>> days ago and don’t see any code changes since.
>>>> 
>>>> Thanks
>>>> Justin
>>>> 
>>>>> On Mar 26, 2020, at 9:59 AM, Umang Modi >>>> <mailto:umangkumarm...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Justin,
>>>>> 
>>>>> I have send a PR for the GPII-4241 issue. Can you please check if it's 
>>>>> correct or not?
>>>>> 
>>>>> Thanks, 
>>>>> Umang Modi
>>>>> 
>>>>> On Wed, Mar 25, 2020, 5:28 PM Justin Obara >>>> <mailto:obara.jus...@gmail.com>> wrote:
>>>>> Hi Umang,
>>>>> 
>>>>> Please don’t include screen shots of code, please include either a link 
>>>>> to the code in your GitHub repo, gist, pastebin, etc or include the code 
>>>>> directly in the e-mail. 
>>>>> 
>>>>>> "Also the issue (GPII-4241 <https://issues.gpii.net/

Re: Finding difficulties in Understanding the structure of the Infusion docs repository

[Justin Obara]

 Hello Jenniline,

The contents of the documentation is stored under 
https://github.com/fluid-project/infusion-docs/tree/master/src/documents 
 the 
other file that may be interesting is 
https://github.com/fluid-project/infusion-docs/blob/master/site-structure.json 


Thanks
Justin

> On Mar 28, 2020, at 4:27 AM, Jenniline Ebai  wrote:
> 
> Hi,  
> I have cloned and Forked the Infusion docs repo. And I have the Infusion docs 
> on my local machine. I am able to access it using the link  
> http://localhost:9778/  in my browser.
> 
> I am currently studying the Infusion docs repo so as to have an understanding 
> of the structure and the codebase. Also, so that I can understand how to 
> structure my proposal since  I am to use another static /documentation site 
> generator like Hugo or Gatsby.
> Those are few of the ones I am currently researching on right now. 
> 
> I am facing difficulties understanding the structure of the Infusion docs 
> repository.
> I will like to know which files or branches are responsible for the different 
> components of the Infusion docs. 
> 
> Please can anyone help me with a description of this? 
> 
> Thanks
> 
> 
>
> 
> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Regarding - Migrate FLOE & Fluid project websites & Refactor Doc

[Justin Obara]

Hi Vaibhav,

Something like that would need to be discussed with the community. You’re 
welcome to add it to your proposal, but I couldn’t tell you right now if it’s a 
change that we’d make at this point.

Thanks
Justin

> On Mar 29, 2020, at 7:02 AM, Vaibhav  wrote:
> 
> Hello,
> 
> I wanted to ask is it possible to combine both of these projects into one for 
> example, instead of creating a separate website for Fluid project and 
> Infusion Docs project (which is present on Fluid project website), why don't 
> we have the docs, blog and other website content on one website. I'm saying 
> this by keeping Docusaurus into consideration.
> 
> Thanks,
> Vaibhav
> 
> 
> 
> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Regarding the project "Port UIO+ Chrome Extension to Firefox and Safari"

[Justin Obara]

Hi Umang,

Please don’t include screen shots of code, please include either a link to the 
code in your GitHub repo, gist, pastebin, etc or include the code directly in 
the e-mail. 

> "Also the issue (GPII-4241 <https://issues.gpii.net/browse/GPII-4241>) 
> suggested a keyboard shortcut. While the suggested one won't work, you can 
> look into creating something similar based off of it."
> Can you please elaborate on what context you're saying it would not work?
> Is it like all the keyboard shortcuts should be same for all machines or is 
> it something else?

In the issue GPII-4241 <https://issues.gpii.net/browse/GPII-4241> it suggests 
using "shift-ctrl-opt-win-u” as the keyboard shortcut. However, the 
chrome.commands <https://developer.chrome.com/apps/commands> API prohibits 
prohibits mixing Ctrl+Alt (in the suggested keyboard shortcut opt is the same 
as alt).

> - Also whenever I'm loading the unpacked extension on Google Chrome I'm 
> getting an error message "WebSocket connection to 
> 'ws://localhost:8081/browserChannel' failed: Error in connection 
> establishment: net::ERR_CONNECTION_REFUSED". I am including the image of the 
> error message below. Please help me fix this error.


That’s because it’s trying to connect to Morphic <https://morphic.world/>  but 
you do not have Morphic running on your machine. Don’t worry about that error 
for now though, it just means that preferences from Morphic won’t be passed 
into the extension.

Thanks
Justin

> On Mar 24, 2020, at 5:16 PM, Umang Modi  wrote:
> 
> Hi Justin, 
> 
> I cloned the entire repo and built the extension locally on my computer. 
> Currently, I'm using Windows 10 OS, and after loading the unpacked extension 
> on Google Chrome I tried using the keyboard shortcut to open the extension 
> panel and I didn't face any issue. 
> "Also the issue (GPII-4241 <https://issues.gpii.net/browse/GPII-4241>) 
> suggested a keyboard shortcut. While the suggested one won't work, you can 
> look into creating something similar based off of it."
> Can you please elaborate on what context you're saying it would not work?
> Is it like all the keyboard shortcuts should be same for all machines or is 
> it something else?
> I'm including an image of the code. Please check if the bug if fixed or not.
> 
> - Also whenever I'm loading the unpacked extension on Google Chrome I'm 
> getting an error message "WebSocket connection to 
> 'ws://localhost:8081/browserChannel' failed: Error in connection 
> establishment: net::ERR_CONNECTION_REFUSED". I am including the image of the 
> error message below. Please help me fix this error.
> 
> Thanks and Regards,
> Umang Modi
> 
> 
> On Tue, Mar 24, 2020 at 9:04 PM Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> Hello Umang,
> 
> Thanks for the PR <https://github.com/GPII/gpii-chrome-extension/pull/49>. 
> I’ve left a review on it.
> 
> Thanks
> Justin
> 
>> On Mar 24, 2020, at 11:13 AM, Umang Modi > <mailto:umangkumarm...@gmail.com>> wrote:
>> 
>> Hi Justin,
>> 
>> I have tried to fix the error in JIRA issue GPII-4241, and created a pull 
>> request. Can you please check if the bug has been fixed or not?
>> 
>> Thanks!
>> Umang Modi
>> 
>> On Tue, Mar 24, 2020 at 12:27 AM Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> Hi Umang,
>> 
>> Some comments inline below.
>> 
>> Thanks
>> Justin
>> 
>>> On Mar 23, 2020, at 2:45 PM, Umang Modi >> <mailto:umangkumarm...@gmail.com>> wrote:
>>> 
>>> Hi Justin, 
>>> 
>>> Thanks for your reply. However, I have a few more doubts. I'm listing them 
>>> down here:
>>> 1. Could you please tell me about the development environment you've used 
>>> while building the current version of the project as It'll help me 
>>> understand all the files better.
>> 
>> Not really sure what you’re looking for here. You can follow the “Building 
>> the extension 
>> <https://github.com/GPII/gpii-chrome-extension#building-the-extension>” 
>> section of the README to get started. 
>> 
>>> 2. In the .editorconfig 
>>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.editorconfig> 
>>> file you have specified all the configurations for the editor, so do we 
>>> have to follow that strictly or we can change that according to our own 
>>> preferences? Please also tell me about the editor you used.
>> 
>> You can use whichever edit

Re: Interest to work with Inclusive Design Institute in GSoC 2020

[Justin Obara]

Hi Dinuka,

Thanks for your interest in our GSoC project, and for all the prep work you’ve 
done so far. However, I’m not really sure what you’re asking for here or the 
purpose of the e-mail. The only thing I can suggest is that you submit proposal 
through the GSoC site.

Thanks
Justin

> On Mar 24, 2020, at 10:17 AM, Dinuka Piyadigama  
> wrote:
> 
> Hi Justin & Cindy,
> 
> I’m Dinuka Piyadigama, a 2nd-year Software Engineering Undergraduate from 
> Informatics Institute of Technology, Sri Lanka. I’m a creative full-stack 
> developer. I'm currently working at a company named ThinkSmart as a back-end 
> developer. In addition to that, currently, I’ve taken up leadership roles in 
> the IET club on Campus IIT, the Blockchain research group of IIT and the 
> Toastmasters club of IIT; where I hold the positions of the vice-president, 
> lead and sergeant-at-arms respectively.
> 
> I'm interested in taking up the project, “Port UIO+ Chrome Extension to 
> Firefox and Safari; add more adaptations”. As a preparation, I started 
> developing sample extensions for Firefox, Chrome & Safari. I faced a problem 
> when trying to get the Safari extension which I developed to work as Safari 
> won’t allow “Unauthorized extensions” to be installed. Can I please know if 
> there’s any workaround for this?
> 
> The GitHub repo which contains the work that I've done with relevance to this 
> project can be found here: https://github.com/DinDev3/BrowserExtensions 
> 
> The ReadMe of the repo contains the steps that I've followed to implement the 
> extensions.
> 
> I have also set-up the preference chrome extension project on my machine and 
> checked out how it works. Screenshots of the testing and running of the 
> project are attached below.
>  
> 
> 
>  
> Looking forward to a positive reply.
>  
> Thank you,
> Regards,
> Dinuka Piyadigama.
> 
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Regarding the project "Port UIO+ Chrome Extension to Firefox and Safari"

[Justin Obara]

Hello Umang,

Thanks for the PR <https://github.com/GPII/gpii-chrome-extension/pull/49>. I’ve 
left a review on it.

Thanks
Justin

> On Mar 24, 2020, at 11:13 AM, Umang Modi  wrote:
> 
> Hi Justin,
> 
> I have tried to fix the error in JIRA issue GPII-4241, and created a pull 
> request. Can you please check if the bug has been fixed or not?
> 
> Thanks!
> Umang Modi
> 
> On Tue, Mar 24, 2020 at 12:27 AM Justin Obara  <mailto:obara.jus...@gmail.com>> wrote:
> Hi Umang,
> 
> Some comments inline below.
> 
> Thanks
> Justin
> 
>> On Mar 23, 2020, at 2:45 PM, Umang Modi > <mailto:umangkumarm...@gmail.com>> wrote:
>> 
>> Hi Justin, 
>> 
>> Thanks for your reply. However, I have a few more doubts. I'm listing them 
>> down here:
>> 1. Could you please tell me about the development environment you've used 
>> while building the current version of the project as It'll help me 
>> understand all the files better.
> 
> Not really sure what you’re looking for here. You can follow the “Building 
> the extension 
> <https://github.com/GPII/gpii-chrome-extension#building-the-extension>” 
> section of the README to get started. 
> 
>> 2. In the .editorconfig 
>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.editorconfig> 
>> file you have specified all the configurations for the editor, so do we have 
>> to follow that strictly or we can change that according to our own 
>> preferences? Please also tell me about the editor you used.
> 
> You can use whichever editor you like, but you must adhere to the coding 
> style.
> 
>> 3. I'm not able to understand the contents of .eslintignore 
>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.eslintignore> 
>> file and for what it is used?
>> 4. I think .eslintrc.json 
>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.eslintrc.json> 
>> file is corresponding to the configuration that we have to include when 
>> setting up ESLint, so do we have to strictly abide by that or can we explore 
>> additional configuration and then later add it in the .eslintrc.json 
>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.eslintrc.json>  
>> file?
> 
> You should look up https://eslint.org <https://eslint.org/> and as mentioned 
> above you must adhere to the coding style. You can propose changes to the 
> coding style if you like, but adoption will affect everyone working on the 
> project. 
> 
>> 5. In the .gitignore 
>> <https://github.com/GPII/gpii-chrome-extension/blob/master/.gitignore> file, 
>> It's suggesting to ignore .nyc_output folder, so is this the same folder 
>> that corresponds to the .nycrc file in the root directory?
> 
> Yes, those are related to output of reports from the testing. 
> 
>> 
>> I would be really thankful if you could find time to answer this.
>> 
>> Regards,
>> Umang Modi 
>> 
>> On Wed, Mar 18, 2020 at 10:39 PM Justin Obara > <mailto:obara.jus...@gmail.com>> wrote:
>> Hi Umang,
>> 
>> I suppose it’s fine to build using a VM; however, unless you have a VM in a 
>> supported cloud environment I’m not sure you’ll be able to run one. The last 
>> I checked, macOS only allowed virtualized macOS instances to run on Apple 
>> hardware. If it isn’t something you can do, and you still want to work on 
>> this project make sure to mention that as part of your proposal and ensure 
>> that the scope and breadth of your work is sufficient for the time.
>> 
>> Thanks
>> Justin
>> 
>> > On Mar 18, 2020, at 11:46 AM, Umang Modi > > <mailto:umangkumarm...@gmail.com>> wrote:
>> > 
>> > Hi everyone,
>> > 
>> > I am Umang Modi, and I would like to contribute in the project "Port UIO+ 
>> > Chrome Extension to Firefox and Safari" but I have some questions 
>> > regarding it and need your help for the same.
>> > 
>> > As in the project description it is written we have to make and add an 
>> > extension that will work in both the Firefox and Safari extensions.
>> > To develop an extension for Safari browser we need Xcode development 
>> > enviroment which is only build for macOS and I don't have access to mac 
>> > operating system.
>> > 
>> > 1.Currently I'm using Windows operating system so can we use virtual 
>> > machine to develop extension for safari browsers?
>> > 2. Will there be any compatibility issues or will there be any issue in 
>