opensourcedesign/events

Open Source design meetup in Berlin

Closed this issue · 25 comments

Hey everyone!

I'm very excited to say that we finally managed to arrange the first open source design meetup in Berlin! \o/

It's going to be in the mozilla community space on March 15th 17th at 7pm. Here's a link to the meetup page that Michael Henretty set up for us.

Is this something we should post on the opensourcedsign page in the events section or should we wait 'till it (hopefully) becomes a regular thing?

Who's in Berlin? @bnvk @ScintillaLuz @Kriesse @gsambrotta @bbalazs @mrflix @jancborchardt and wants to join? Would love to see/meet as many of us as possible there :D

Is the meeting on the 15th (as the post says) or the 17th (as meetup claims)?

It's on the 17th. Sorry. I changed it in the original message.

Can we get a link to http://opensourcedesign.net in the event on https://www.meetup.com/Berlin-Mozilla-Meetup/events/238236462/ and call it »Open Source Design« @mikehenrty :)

Btw, the old-schoolers @bnvk @danilapellicani @Kriesse @gillisig will know we already had an Open Source Design meetup in Berlin way back in early 2015. ;)
http://opensourcedesign.net/events/2015/03/15/berlin-open-source-design-meetup

Can we get a link to http://opensourcedesign.net in the event on https://www.meetup.com/Berlin-Mozilla-Meetup/events/238236462/ and call it »Open Source Design« @mikehenrty :)

Done! Let me know if you need anything else.

@mikehenrty awesome, thank you! :)

At the meetup, @Incabell will also talk to you about the possibility of using the Mozilla event space as a venue for our planned Open Source Design Summit October 13–18 (on the Monday-Tuesday, if possible): opensourcedesign/organization#59 (comment) – would be cool :)

@Incabell @jdittrich can you also add it as an event to the opensourcedesign.net/events page? :)

done, with just 1 minor embarrassing hiccup \o/

@Incabell no worries! :D Next time best use a new branch + pull request for that, then it can be reviewed by others and hiccups can be avoided. :)

At the meetup, @Incabell will also talk to you about the possibility of using the Mozilla event space as a venue for our planned Open Source Design Summit October 13–18 (on the Monday-Tuesday, if possible): opensourcedesign/organization#59 (comment) – would be cool :)

This sounds great! By that time, we will have moved to our new space at Schlesisches Tor, and will be able to accommodate many more people in our event space. Stuff like this is exactly why we are moving there, so this makes me happy 🕺

Now there’s also a tweet to spread the word:
https://twitter.com/opensrcdesign/status/839875262351360001

(@Incabell @jdittrich you are welcome to tweet from the account too, as said :)

@mikehenrty yeaaay! :)

Here the tricky way to Mozillas Event space: https://docs.google.com/document/d/1bwI3ztOV4WRpg_xCy4etR7DJ2oL2UfltF2O8m6WwFFQ/edit
(could also be a game solution: Walk past the gate… pick up the mate… level completed. Cutscene to meetup)

Here the etherpad link with the documentation https://etherpad.wikimedia.org/p/opensourcedesign170416

Current state:
Open Source Design Meetup Berlin, @mozilla
17.03.17
Attendees: Jan D, Jan M, Peter, Heiko, Hernan, Charlie, Sam, Michael, Ettore, Amin, Tobias. Did I miss anybody?
https://www.meetup.com/de-DE/Berlin-Mozilla-Meetup/events/238236462/?eve
goals of this meeting (?):

  • how can we build community for usability/design people to support each other?
  • it doesn't work so well to integrate design & usability ideas into traditional (code-centric) open source projects - how can we create a more neutral field for non-code contributors to take part?

Jan Muehlig talked about his own experience of successes and failures in regards to bringing usability concepts into F/LOSS projects - many different research projects were undertaken (eg during the Season of Usability, though often efforts fell short when it came to developers actually implementing the lessons learned.

Stumbling blocks were often the code-centric culture of open source - a 'contributor' is someone who writes code - that is the traditional way into a community of trust and collaboraion. There was often no way in for UX or other non-code contributions.

Various hurdles were discussed - one interesting aspect of F/LOSS development is that there are many mechanisms to 'add' features... but none to 'remove' them!
The idea that 'the bigger the buffet, the better it must be' prevails and leads to bloated, confusing, awkward jack-of-all-trades software.

Sam shared an example of successful community integration/transition from Kdenlive, the video editor he relies upon for work (https://kdenlive.org/). For many years almost all of the code has come from only one developer, Jean-Baptiste Mardelle - and as you might expect, he burned out and almost left the project for good back in 2013. But in the last two years there has beeen a resurgence of enthusiasm and activity around Kdenlive, led by a small group of active users, design and documentation contributors, together with JBM and other programmers, focused around informal IRC chats called 'Kdenlive Cafés', in which technical and creative aspects of video editing are discussed, as well as use of the software, bugs and features, and the progress of Kdenlive as a community and project. 'Bug squashing days' were organised with different roles for different technical abilities, and strategies to bring in more developers were fleshed out. This helped form a sense of community and shared stewardship of the project, got it out of a rough patch from a development, and made clear to everybody what value there can be in non-code contributions. Obviously this is a special case because a sole-developer at the point of burnout creates a power vacuum which doesn't exist in many other F/LOSS projects, but I think the not-entirely-technical Café can be a good way in for non-code contributors even within traditionally code-centric projects.

We talked a lot about user testing, and differences between the open and closed worlds. eg Amazon is constantly A/B testing, netflix too - gathering customer feedback all the time as well.

There's a common myth that user testing is all or nothing - you either have a uni research team with proper lab methods, or not at all. But even flawed user prototyping (eg testing on your own team) can be useful in a way, even if it's not optimal it's better than nothing (as long as you acknowledge that it is flawed). [Jan D.: read on paper prototyping, discount usability testing or guerilla reserach if you are interested]

A question was asked about the 2007 example of InGimp as a way to automate user testing:
https://www.linux.com/news/ingimps-tools-may-improve-foss-usability
Peter was working with Gimp at the time, so could offer some insight:
"ingimp was an interesting but flawed experiment. It didn't work because you don't understand the data. You don't know what someone was thinking when they clicked there - was that long pause because they didn't know what to do, or because they got a phone call? Quantative data without context isn't much help."
However, some group members advocated for using such quantitative data, but not as the only source used for development.

elementary, gnome, nextcloud as positive examples of design-inclusive communities.
usually these are the newer projects.

We discussed more radical approaches... "ok, I have a stupid idea... what about a governance fork to force culture change?"
maintaining the same codebase - with a different set of values.
"I can make your idea even worse: parallel maintainership - code on one side, design and usability on the other, wiith consensus needed before a release."

Ok, we need to have a meeting together with developers to talk about this topic. Try to understand difficulties on both sides and start something together.

We then split into 3 groups for more focused discussions:

Links:
- thesis: https://www.dgsiegel.net/news/2012_12_09-typical_development_processes_of_free_and_open_source_software_projects

Crowdsourcing/design: http://spdow.ucsd.edu/

TOOLS: what do we have? what are we missing?

  • Justinmind is interesting but closed source
  • Jan D. uses LO draw
  • Is paying for tools ok? We all do to various degrees, and to various degrees, it is seen as not-the-right thing becuase of ethics and disabling collaboration.
  • Pidoco for collaboration (closed source)
  • Not the tool is the problem but that the format are not free
  • Jitsi, Hangouts for the process
  • Writing on an image of the screen while user testing (highlighting) may be a cool plugin for jitsi
  • Extending etherpad?
  • Bugzilla "broke down" when UX Bugs were involved: The usual single theraded structure for tackling well defined problems could not be used well for mutiple-layers, wicked, desinerly problems.

COMMUNITY: how do we engage UX & design people with OS, and vice versa? How can we build a community around this idea?

  • How can we counter fears of Designers
  • Just take my designer
  • I cant code
    
  • How can we organize a community 
    
  • How can we define a common interest
    • Projects-Centric? UX? Visual?
      
  • Documenting Knowledge as a culture
    
  • Best practices
    
  • Build up experiences and skills
    
  • Making it accessible 
    
  • Onboarding
  • Matching people with projects
  • Incentivize being part of the community
  • Learning and failures
  • Code of Conduct for projects that want to collaborate with the community to protect the community
  • Community activities
  • Communicating the mission
  • How do people get to know about us
  • Need for funding, having a small hackathon etc.

Comment:

  • Diversity on the "simple" level of "it is not just code" AND it may also be a step into the direction of "there are any different people/approaches to add to our projects"

POSITIVE CASES

  • Elementery attracted people who were interested in BUILDING and DESIGN https://.twitter.com/elementary/status/842462739536719875
  • …but maybe they have a core group of people, onboarding not very visible
  • Gnome: Redshift had a well structured dialog between the design oriented community members with the developers
  • They documented best practices e.g. what they did if something could not be implemented in the GTK lib
  • JASP may be an example for another successful tool: they want to build a statistics application ßthat can be used by beginners. One incentive is that they want to make an often overlooked branch of statistics, bayesian testing, more visible (and better taught). They are backed by unis, funding and statisticians interested in education. Jamovi is a more feature oriented branch, interesting how they will fare, design wise. [Added in discussion]
  • As a dev you get in contact with other peoples code; for designers it is very different; designers could do it differently
  • Maybe templates for people to express their ideas. Could be visual, resources etc.
  • An dev can build upon libs by others. Can a designer build upon?
  • A treasure trove for designers

how can we build and integrate a non-dev community? to recruit/onboard/make them happy.

open usability: tackled universities
usability professional association:
take real issues to universities.

forum/exchange platform
want to get out of cocoon, and widen his vision, and do design in a big process.
where were they successful or didn't succeed.

how can we define a common interest?
how can we organise the community?
how can we make a successful onboarding process?
how can we incentivise being part of the community? engage people
how can we counter fears? identify them as well
how can we build up and spread FOSS experiences and skills?
how can we document UX knowledge?
how can we match contributors with open source projects?
Code of conduct for projects
Permanent learning from projects including failures.
How can we fund the community activities?
communicating the open source ux movement. advertising. how do people know about us?

Next meetup coming on Thur April 20th, again at Mozilla; no specific time set yet, but I strongly assume it is 19:00 again :)
Suggested Topic: Starting a small, outcome oriented OSD experiement #76 – maybe the survey.

Yep, let’s simply use 19:00 as the standard time. :)

Also, I would suggest making the meetups action-oriented. Like working on the site, or preparing participation at a conference. Not just talking. ;)

Also, I would suggest making the meetups action-oriented. ;)

Thus, the suggestion to work on the survey. (btw.: I would think that having no focus or common graspable problem would be bad – talking itself I don't see as a problem)

@elioqoshi any news on organizing the meetup on the 26th after the OpenTechSummit? :)

Also come to our Open Source Design track at OpenTechSummit Berlin-Potsdam next week :)
https://twitter.com/opensrcdesign/status/865185759246077952

There’s free tickets as long as they last at https://eventyay.com/e/5642d9a1/?code=OPENDESIGN, and if you have last-minute talk proposals please let me know! @Kriesse @Incabell @mrflix

@jancborchardt sorry for the delay, crazy even post-OSCAL. Yeah I asked Mike Henretty and still awaiting a reply. Assume it will happen, as I can take care of it as Mozilla staff

P.S: Will be at OpenTechSummit as well. Cya there

What time do you prefer? 5pm? 6pm?

As said above usually meetups are done at 7pm cause people are still at work earlier. :)

@elioqoshi sorry, I must have missed your ping! What would you need from me here? Unfortunately, I'll be out of the country on May 26th, but as staff you can host it yourself :)

can we close this event?

@evalica yeah, I would say we can close this in favor of the forum thread at https://discourse.opensourcedesign.net/t/berlin-germany/97 – in the Local meetups category there’s also other active groups. :)

@jdittrich do you maybe want to craft an article for our website out of what you wrote at #69 (comment) ? :)