openscienceroadmap / roadmap Goto Github PK

From @Daniel-Mietchen on April 29, 2018 1:51

Whether this is a visualization, a sonification, a haptic experience, a game, a cartoon, a 3D print or something else, the important point here is to allow people — and perhaps machines as well — to explore certain aspects of the open science ecosystem or its evolution in an intuitive way that works at different levels of familiarity with the matter.

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#5

From @dwhly on May 5, 2018 1:47

@bmkramer and @JeroenBosman have done excellent work in this area, here. Though it's remit was scholarly communication, and not open science more broadly.

What are others? How can we best construct an ecosystem map that serves our purposes?

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#11

From @Daniel-Mietchen on May 12, 2018 0:35

A very basic version sits at https://tools.wmflabs.org/scholia/topic/Q309823 , biased towards publications I am aware of.

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#23

From @Daniel-Mietchen on April 29, 2018 1:45

In order to create a Joint Roadmap for Open Science Tools, we need to have a closer look at individual examples of tools, services or other components of the open science ecosystem, and find ways to map them on a joint timeline.

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#4

From @Daniel-Mietchen on April 29, 2018 3:13

• Think about questions that you or others might have about open science tools or infrastructure
• Collect similar questions that have been posted elsewhere
• Add them to https://ask-open-science.org/tag/tools or https://ask-open-science.org/tag/infrastructure
• Collect and add useful answers

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#6

From @dwhly on May 5, 2018 1:35

There are things that many science projects, experiments or other collaborations might tend to want or need. We should categorize those and provide leading examples of known solutions in those categories. It's possible there are already good inputs / catalogs that already exist. What are they?

Potential categories might include:

Project management
Collaboration
Issue tracking
Code and data repositories
Manuscript authoring
Publishing
Peer review
Data analysis / Machine learning
Image processing

What are your suggestions?

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#10

From @dwhly on May 1, 2018 20:5

Based on our personas, and the real world needs of those personas, imagine user stories that characterize new capabilities that do not yet exist either within individual projects, or more importantly between two or more projects, that allow people to get things done they wouldn't have been able to before, or to do so more effortlessly or efficiently such that there is a transformative change in capacity or productivity.

These user stories might imply the creation of new standards, or practices, expanding or normalizing APIs, integrating common systems like identity, authentication, data handling, harmonizing user interface or simply creating new features that did not exist before.

These user stories might be quite narrow, and talk about existing projects, or they might be more broad-- such as, "As a user I need to be able to be signed into as a user across any project I'm working on, so that those projects can leverage a common identity and more easily move data between them."

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#8

From @Daniel-Mietchen on April 29, 2018 1:34

Personas are stories that highlight key elements of user experience in a way that helps developers and designers create and improve such experiences — check out how Mozilla put it.

For our purposes, personas would be useful that concentrate on

• how users interact (or would like to) with existing tools in the open science landscape
• tools, services or interactions missing in the open science landscape
• scenarios where open workflows are lagging behind closed ones
• anything annoying that drives people (or machines) away from open science workflows

and similar issues.

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#3

From @bmkramer on May 9, 2018 8:17

Has it already been decided what criteria will be used to assess openness of projects/tools/platforms to be included in the roadmap? (and perhaps also to identify areas where improvement is recommended)?

For instance, the [Principles of Open Scholarly Infrastructure] (http://dx.doi.org/10.6084/m9.figshare.1314859) might be useful for assessing the infrastructure of tools and platforms. Perhaps in combination with aspects of the FORCE11 principles of the scholarly commons (see also preprint) for both the openness of resulting research objects (Open, FAIR and citable) and openness to participation.

Full disclose: this ties in closely to some of the work we are ourselves planning to do over the next months*, and it would be great to see if we can collaborate!

*See the proposals for FORCE2018 that @JeroenBosman and I put in:

• On the positive side: workflows with commons-compliant tools and platforms
• If you build it (open), do they come?

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#13

From @Daniel-Mietchen on May 1, 2018 12:43

Some guidance is available at
https://www.wikidata.org/wiki/Wikidata:WikiProject_Open .

The focus here is on improving existing items. If you're not sure whether something you're interested in has or, or should have one, please leave a comment here or on the Discussion page of the above WikiProject.

Copied from original issue: OpenScienceRoadmap/mozilla-sprint-2018#7