Re: ILDH design update - repo?

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

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 wrote: > > While this has

Re: Archived repositories and the living infrastructure

I wonder if it’s also time for us to consider how/if we use 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

Re: Enabling Github Issues for Infusion project

I don’t think it’s a good idea to have two issue trackers for Infusion since it will most likely result in a lot of confusion and extra maintenance overhead. Are you suggesting we move to github issues from JIRA? Michelle > On Jan 8, 2020, at 10:25 AM, Jonathan Hung wrote: > > Hi everyone,

Re: Which CMS to use for new site?

Hi Gregor, Thanks for outlining the requirements and options. My feeling with NetlifyCMS is that it hasn’t matured to a point where a non-technical user can use it well. Perhaps Dana has more insight into this as she’s been using it for the SJRK site. Michelle > On Aug 15, 2019, at 9:36

Re: Documentation gap for Prefs Framework, and UIO confusion

It’s my understanding that as new features became ready for general use we would add them to UIO. I wonder if it’s time to take a look at the new features that have been added to the preferences framework and add the ones that we think should be integrated by default to UIO. This might address

Story Builder Updates

Hey everyone, We’ve been making some updates to the SJRK/Floe Story Builder to prepare for some upcoming story telling events aimed at gathering stories about learning. The first event is happening tomorrow and we’ve decided to freeze the code where it’s currently at. We’ll be doing a lot of

Recap of Co-design with SEWA in Ahmedabad, India

Hi everyone, Later today Dana and I will give a recap of our trip to India and the co-design we did there. Hope you can make it! Tuesday December 11, 2:30 Eastern in the standup Vidyo room. Michelle ___ fluid-work mailing list -

Re: Proposals to cleanup fluid-project GitHub repositories

I really like the idea of archiving projects that we don’t expect to get back to which I think is the majority of your list. I would rather us not archive repos that we do expect to work on again. In your list, I think these fall into this category:

Re: State of the art of developer support

Hi Steve, One of the things we do as the Fluid community is create resources to assist people with learning about a11y and thinking about it from the beginning. We’ve been collecting our resources here: https://wiki.fluidproject.org/display/fluid/Inclusive+Design+Toolkit

Re: Code of Conduct

There are some issues with the blog post you quoted, from an Inclusive Design perspective. To start with, the author dismisses the idea of a code of conduct as 'political correctness’. This is very disturbing because when you break it down, it seems like it is saying that ‘there are things I

Sonification on Spark

I was telling a friend about our sonification work and he mention this: http://www.cbc.ca/radio/spark/296-sleep-secrets-drone-danger-and-more-1.3265562/listen-to-the-music-this-man-makes-out-of-ordinary-data-1.3270839

Planning Learning Dashboard Related Work

Let’s meet on Monday, December 14 at noon eastern to continue the planning work for our learning dashboard. Michelle ___ fluid-work mailing list - fluid-work@lists.idrc.ocad.ca To unsubscribe, change settings or access archives, see

Re: Uglify modifies code in minified builds

Thanks for looking into this Justin. I think we should disable the compression options. Leaving the compression options on means that the minified code base is considerably different from the unminified code base. I don’t think the small change in file size is worth the increased complexity