diff --git a/D2.5_Second release of OSD status report dashboard_UBA.fodt b/D2.5_Second release of OSD status report dashboard_UBA.fodt index 5fad495..72d6245 100644 --- a/D2.5_Second release of OSD status report dashboard_UBA.fodt +++ b/D2.5_Second release of OSD status report dashboard_UBA.fodt @@ -1,24 +1,24 @@ - Pen-Yuan HsingPen-Yuan Hsing2212021-06-14T17:44:002021-06-14T17:44:002022-11-17T13:59:23.564264400PT17H36M7SLibreOffice/7.4.2.3$Linux_X86_64 LibreOffice_project/382eef1f22670f7f4118c8c2dd222ec7ad009daf + Pen-Yuan HsingPen-Yuan Hsing2272021-06-14T17:44:002021-06-14T17:44:002022-11-28T14:12:28.817960688PT21H14M35SLibreOffice/7.4.3.2$Linux_X86_64 LibreOffice_project/1048a8393ae2eeec98dff31b5c133c5f1d08b890 - 0 + 811918 0 - 41829 - 20816 + 33450 + 19978 true false view2 - 18283 - 9483 + 11308 + 811964 0 - 0 - 41827 - 20814 + 811918 + 33449 + 831894 0 1 false @@ -91,7 +91,7 @@ true true - 2356745 + 2504726 true false @@ -163,6 +163,7 @@ + @@ -173,7 +174,7 @@ - + @@ -196,8 +197,8 @@ - - + + @@ -396,6 +397,10 @@ + + + + @@ -3712,930 +3717,962 @@ - - + + - + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + - + - + + + + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - - - - + + + + + - - + + + + + - - + + + - - + + - - + + - + - + - + - + - + - + - - - - - - - - - - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + + - - + + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + + - - - - - - @@ -4682,297 +4719,309 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + + + + - + + + + + + + @@ -7542,16 +7591,16 @@ - - - - - - - OPEN_NEXT + + + + + + + OPEN_NEXT Deliverable 2.5 - Second release of OSD status report dashboard - + Second release of OSD status report dashboard + @@ -8993,293 +9042,293 @@ - # + # - Participant Legal Name + Participant Legal Name - Short Name + Short Name - Country + Country - 1 + 1 - TECHNISCHE UNIVERSITAT BERLIN + TECHNISCHE UNIVERSITAT BERLIN - TUB + TUB - DE + DE - 2 + 2 - INSTITUT POLYTECHNIQUE DE GRENOBLE + INSTITUT POLYTECHNIQUE DE GRENOBLE - GINP + GINP - FR + FR - 3 + 3 - ALEXANDER VON HUMBOLDT-INSTITUT FURINTERNET UND GESELLSCHAFT GGMBH + ALEXANDER VON HUMBOLDT-INSTITUT FURINTERNET UND GESELLSCHAFT GGMBH - HIIG + HIIG - DE + DE - 4 + 4 - UNIVERSITY OF BATH + UNIVERSITY OF BATH - UBA + UBA - UK + UK - 5 + 5 - ZENTRUM FUR SOZIALE INNOVATION GMBH + ZENTRUM FUR SOZIALE INNOVATION GMBH - ZSI + ZSI - AT + AT - 6 + 6 - FRAUNHOFER GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V. + FRAUNHOFER GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V. - FHG + FHG - DE + DE - 7 + 7 - DANSK DESIGN CENTER APS + DANSK DESIGN CENTER APS - DDC + DDC - DK + DK - 8 + 8 - WIKIMEDIA DEUTSCHLAND - GESELLSCHAFT ZUR FÖRDERUNG FREIEN WISSENS EV + WIKIMEDIA DEUTSCHLAND - GESELLSCHAFT ZUR FÖRDERUNG FREIEN WISSENS EV - WMDE + WMDE - DE + DE - 9 + 9 - WIKIFACTORY EUROPE SL + WIKIFACTORY EUROPE SL - WIF + WIF - ES + ES - 10 + 10 - STICHTING WAAG SOCIETY + STICHTING WAAG SOCIETY - WAAG + WAAG - NL + NL - 11 + 11 - MAKER + MAKER - MAK + MAK - DK + DK - 12 + 12 - AGILE HEAP EV + AGILE HEAP EV - FLB + FLB - DE + DE - 13 + 13 - SONO MOTORS GMBH + SONO MOTORS GMBH - SOM + SOM - DE + DE - 14 + 14 - OPNTEC GMBH + OPNTEC GMBH - OPT + OPT - DE + DE - 15 + 15 - STYKKA APS + STYKKA APS - STY + STY - DK + DK - 16 + 16 - TILL WOLFER + TILL WOLFER - XYZC + XYZC - DE + DE - 17 + 17 - FICTION FACTORY + FICTION FACTORY - FIF + FIF - NL + NL - 18 + 18 - M2M4ALL + M2M4ALL - SOD + SOD - NL + NL - 19 + 19 - INNOC OSTERREICHISCHE GESELLSCHAFT FUR INNOVATIVE COMPUTERWISSENSCHAFTEN + INNOC OSTERREICHISCHE GESELLSCHAFT FUR INNOVATIVE COMPUTERWISSENSCHAFTEN - HAL + HAL - AT + AT - + Duration: 09/2019-08/2022 Grant: H2020-869984 - Contact (coordinator): Prof Dr-Ing Roland JOCHEMAddress: Technische Universität Berlin, Sekretariat PTZ 3, Pascalstr. 8-9, 10587 BerlinE-mail: roland.jochem@tu-berlin.de - - Disclaimer: The contents of this document are not intended to replace consultation of any applicable legal sources or the necessary advice of a legal expert, where appropriate. All information in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The user, therefore, uses the information at his/her sole risk and liability. For the avoidance of all doubts, the European Commission has no liability in respect of this document, which is merely representing the views of the author(s). + Contact (coordinator): Prof Dr-Ing Roland JOCHEMAddress: Technische Universität Berlin, Sekretariat PTZ 3, Pascalstr. 8-9, 10587 BerlinE-mail: roland.jochem@tu-berlin.de + + Disclaimer: The contents of this document are not intended to replace consultation of any applicable legal sources or the necessary advice of a legal expert, where appropriate. All information in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The user, therefore, uses the information at his/her sole risk and liability. For the avoidance of all doubts, the European Commission has no liability in respect of this document, which is merely representing the views of the author(s). D2.5 – “Second release of OSD status report dashboard” - Review and approval status: + Review and approval status: @@ -9287,104 +9336,104 @@ - + - Name and Surname + Name and Surname - Role in the Project + Role in the Project - Partner + Partner - Author + Author - Pen-Yuan HSING + Pen-Yuan HSING - Researcher + Researcher - UBA + UBA - + - Elies DEKONINCK + Elies DEKONINCK - Researcher + Researcher - UBA + UBA - + - Rafaella ANTONIOU + Rafaella ANTONIOU - Researcher + Researcher - UBA + UBA - Reviewed by + Reviewed by - Sonika GOGINENI + Sonika GOGINENI - Researcher + Researcher - GINP + GINP - + - Martin HÄUER + Martin HÄUER - Researcher + Researcher - FHG + FHG - Approved by + Approved by - Robert MIES + Robert MIES - Project manager + Project manager - TUB + TUB - History of changes: + History of changes: @@ -9392,118 +9441,118 @@ - Version + Version - Date + Date - Description of changes + Description of changes - By + By - 0.1 + 0.1 - 14.08.2022 + 14.08.2022 - Initial draft + Initial draft - Pen-Yuan HSING + Pen-Yuan HSING - 1.0 + 1.0 - 30.08.2022 + 30.08.2022 - First version for submission for M36 + First version for submission for M36 - Pen-Yuan HSING + Pen-Yuan HSING - Details: + Details: - Dissemination level + Dissemination level - Open Access + Open Access - Due date + Due date - 31.08.2022 + 31.08.2022 - Issue date + Issue date - 15.08.2022 + 15.08.2022 - Contract No. + Contract No. - 869984 + 869984 - Responsible Partner + Responsible Partner - UBA + UBA - File name + File name - D2.5_Second release of OSD status report dashboard_UBA.fodt + D2.5_Second release of OSD status report dashboard_UBA.fodt - Digital object identifier (DOI) + Digital object identifier (DOI) - 10.5281/zenodo.6991166 + 10.5281/zenodo.6991166 - Keywords: + Keywords: Open source hardware, open design, open source development, health metrics - Executive Summary: + Executive Summary: - Targeted at platforms which host the code and design files of open source hardware projects (such as Wikifactory of GitHub), the goal of T2.2 in the OPEN_NEXT project is to design and deliver project status dashboards that visualise key metrics of those projects. - In this D2.5 report, we describe the methodology we undertook after D2.3 to refine the features desired for the dashboard with a focus on WIF needs. Using WIF feedback, we have re-architected the dashboard technical infrastructure to be more modular. Those who utilise it can choose which components to reuse or implement on their own. This report also describes in detail step-by-step deployment and usage instructions for the dashboard backend and demo frontend. - Importantly, the code underlying D2.5 has been integrated into Wikifactory, and certain frontend features are already implemented. These feature will be made accessible to many projects hosted there starting September 2022. + Targeted at platforms which host the code and design files of open source hardware projects (such as Wikifactory of GitHub), the goal of T2.2 in the OPEN_NEXT project is to design and deliver project status dashboards that visualise key metrics of those projects. + In this D2.5 report, we describe the methodology we undertook after D2.3 to refine the features desired for the dashboard with a focus on WIF needs. Using WIF feedback, we have re-architected the dashboard technical infrastructure to be more modular. Those who utilise it can choose which components to reuse or implement on their own. This report also describes in detail step-by-step deployment and usage instructions for the dashboard backend and demo frontend. + Importantly, the code underlying D2.5 has been integrated into Wikifactory, and certain frontend features are already implemented. These feature will be made accessible to many projects hosted there starting September 2022. @@ -9615,36 +9664,36 @@ Table of contents - 1 Introduction7 - 1.1 Structure of this report8 - 2 Requirements capture8 - 2.1 Stakeholder types and needs9 - 2.2 Mapping information needs to specific features12 - 2.3 Feature prioritisation12 - 3 Design and implementation13 - 3.1 WIF implementation of dashboard frontend14 - 4 User feedback15 - 4.1 Survey design15 - 4.2 Survey deployment17 - 4.3 Results and discussion18 - 5 Step-by-step installation and use of sample dashboard implementations19 - 5.1 Backend19 - Running from source20 - Deploy as container21 - 5.2 Usage22 - Making requests to the REST API22 - API response format23 - Custom Wikifactory URLs26 - 5.3 Frontend sample implementation26 - Running locally from source26 - Deploy to web27 - 5.4 Usage28 - 6 Summary30 - 7 Acknowledgements31 - 8 Annex32 + 1 Introduction7 + 1.1 Structure of this report8 + 2 Requirements capture8 + 2.1 Stakeholder types and needs9 + 2.2 Mapping information needs to specific features12 + 2.3 Feature prioritisation12 + 3 Design and implementation13 + 3.1 WIF implementation of dashboard frontend14 + 4 User feedback15 + 4.1 Survey design15 + 4.2 Survey deployment17 + 4.3 Results and discussion18 + 5 Step-by-step installation and use of sample dashboard implementations19 + 5.1 Backend19 + Running from source20 + Deploy as container21 + 5.2 Backend usage22 + Making requests to the REST API22 + API response format24 + Custom Wikifactory URLs26 + 5.3 Frontend sample implementation26 + Running locally from source27 + Deploy to web27 + 5.4 Demo frontend usage28 + 6 Summary30 + 7 Acknowledgements31 + 8 Annex32 - List of abbreviations and terms + List of abbreviations and terms API Application programming interface BOMBill of materials CADComputer-aided design @@ -9655,125 +9704,125 @@ JPLJet Propulsion Laboratory JSONJavaScript object notation HTMLHypertext markup language - NASANational Aeronautics and Space Administration + NASANational Aeronautics and Space Administration OSH Open source hardware OSDOpen source development RESTRepresentational state transfer SME Small and medium-sized enterprises - Tx.yOPEN_NEXT task x.y + Tx.yOPEN_NEXT task x.y URLUniversal resource locator WIFWikifactory WPWork package WSGIWeb server gateway interface - List of figures - Figure 1. Final technical architecture for the D2.5 project status dashboard. - Figure 2. License information component of the dashboard frontend delivered in D2.5. - Figure 3. Dashboard element showing breakdown of file types in the project. - Figure 4. Images of dashboard frontend features with labels under each. - Figure 5. Screenshot from a typical page of the dashboard survey. - Figure 6. Initial view of demo frontend. - Figure 7. Choosing a GitHub repository to show visualisations for. - Figure 8. Partial screenshot of some visualisations on the dashboard frontend. - Figure 9. Drag box to zoom into plots. - Figure 10. Tool tips for slices in pie charts. - Figure 11. Additional tools for each visualisation. - List of tables - Table 1. Strength of associations (indicated by “+”s, maximum two) between stakeholders and their needs as exemplified on Wikifactory. - Table 2. Dashboard features linked to stakeholder information needs (“+” indicates a clear relationship). - Table 3. Definitions of dashboard features. Items in bold were prioritised during the requirements capture exercise. - Introduction - OPEN_NEXT is a collaboration between 19 industry and academic partners across Europe. Funded by the European Union’s Horizon 2020 programme, this project seeks to enable small and medium enterprises (SMEs) to work with consumers, makers, and other communities in rethinking how products are designed and produced. Open source hardware1 - https://www.oshwa.org/definition/ is a key enabler of this goal where the design of a physical product is released with complete freedoms for anyone to study, modify, share, and redistribute copies and derivatives. These essential freedoms are based on those of open source software, which is itself derived from free software where the word “free” refers to freedom, not free-of-charge. When put in practice, these freedoms could potentially not only reduce proprietary vendor lock-in, planned obsolescence, or waste but also stimulate novel – even disruptive – business models. The SME partners in OPEN_NEXT are experimenting with producing open source hardware and even opening up the development process to wider community participation. They produce diverse products ranging from desks, cargo bike modules, to a digital scientific instrument platform and more. - Work package 2 (WP2) of OPEN_NEXT is gathering theoretical and practical insights on best practices for company-community collaboration when developing open source hardware. This includes running Delphi studies to develop a maturity model to describe the collaboration or developing a precise definition for what the “source” is in open source hardware. In particular, T2.2 in this work package developed a project dashboard with various indicators showing the status of a project derived from their public repositories. Such a dashboard would comprise of summary visualisations presented on a webpage, which could be optionally integrated into a project hosting platform such as Wikfactory (WIF). For D2.5, we have built on successes so far to implement a new technical architecture for the dashboard; conduct a requirements capture exercise and survey of practitioners to enumerate and prioritise features for the dashboard; delivered updated demonstrators representing key components of the dashboard backend and frontend; and helped WIF integrate those components to realise real business value for the open source hardware projects hosted on their platform. - To jump directly to install and step-by-step usage information (with screenshots) for the code written for D2.5, please see the “5. Step-by-step installation and use of sample dashboard implementations“ section belowto get up and running. For more details on its background, design considerations, and the development of D2.5 please see sections 1through 4. - In this report, any mention of directories, folders, or files are relative to the root directory of the following code repositories: - https://github.com/OPEN-NEXT/wp2.2_dev (DOI: 10.5281/zenodo.4560580) - https://github.com/OPEN-NEXT/wp2.2_frontend_dev (DOI: 10.5281/zenodo.6991170) - In addition, the organisation of these two repositories aims to follow international standards and good practices in open source development such as, but not limited to: + List of figures + Figure 1. Final technical architecture for the D2.5 project status dashboard. + Figure 2. License information component of the dashboard frontend delivered in D2.5. + Figure 3. Dashboard element showing breakdown of file types in the project. + Figure 4. Images of dashboard frontend features with labels under each. + Figure 5. Screenshot from a typical page of the dashboard survey. + Figure 6. Initial view of demo frontend. + Figure 7. Choosing a GitHub repository to show visualisations for. + Figure 8. Partial screenshot of some visualisations on the dashboard frontend. + Figure 9. Drag box to zoom into plots. + Figure 10. Tool tips for slices in pie charts. + Figure 11. Additional tools for each visualisation. + List of tables + Table 1. Strength of associations (indicated by “+”s, maximum two) between stakeholders and their needs as exemplified on Wikifactory. + Table 2. Dashboard features linked to stakeholder information needs (“+” indicates a clear relationship). + Table 3. Definitions of dashboard features. Items in bold were prioritised during the requirements capture exercise. + Introduction + OPEN_NEXT is a collaboration between 19 industry and academic partners across Europe. Funded by the European Union’s Horizon 2020 programme, this project seeks to enable small and medium enterprises (SMEs) to work with consumers, makers, and other communities in rethinking how products are designed and produced. Open source hardware1 + https://www.oshwa.org/definition/ is a key enabler of this goal where the design of a physical product is released with complete freedoms for anyone to study, modify, share, and redistribute copies and derivatives. These essential freedoms are based on those of open source software, which is itself derived from free software where the word “free” refers to freedom, not free-of-charge. When put in practice, these freedoms could potentially not only reduce proprietary vendor lock-in, planned obsolescence, or waste but also stimulate novel – even disruptive – business models. The SME partners in OPEN_NEXT are experimenting with producing open source hardware and even opening up the development process to wider community participation. They produce diverse products ranging from desks, cargo bike modules, to a digital scientific instrument platform and more. + Work package 2 (WP2) of OPEN_NEXT is gathering theoretical and practical insights on best practices for company-community collaboration when developing open source hardware. This includes running Delphi studies to develop a maturity model to describe the collaboration or developing a precise definition for what the “source” is in open source hardware. In particular, T2.2 in this work package developed a project dashboard with various indicators showing the status of a project derived from their public repositories. Such a dashboard would comprise of summary visualisations presented on a webpage, which could be optionally integrated into a project hosting platform such as Wikfactory (WIF). For D2.5, we have built on successes so far to implement a new technical architecture for the dashboard; conduct a requirements capture exercise and survey of practitioners to enumerate and prioritise features for the dashboard; delivered updated demonstrators representing key components of the dashboard backend and frontend; and helped WIF integrate those components to realise real business value for the open source hardware projects hosted on their platform. + To jump directly to install and step-by-step usage information (with screenshots) for the code written for D2.5, please see the “5. Step-by-step installation and use of sample dashboard implementations“ section belowto get up and running. For more details on its background, design considerations, and the development of D2.5 please see sections 1through 4. + In this report, any mention of directories, folders, or files are relative to the root directory of the following code repositories: + https://github.com/OPEN-NEXT/wp2.2_dev (DOI: 10.5281/zenodo.4560580) + https://github.com/OPEN-NEXT/wp2.2_frontend_dev (DOI: 10.5281/zenodo.6991170) + In addition, the organisation of these two repositories aims to follow international standards and good practices in open source development such as, but not limited to: - SDPX 3 compliance with a LICENSE file (also see License section at the end of this user guide) + SDPX 3 compliance with a LICENSE file (also see License section at the end of this user guide) - REUSE 3.0 compliance with appropriate machine-readable SPDX metadata for all files and license texts in the LICENSES directory + REUSE 3.0 compliance with appropriate machine-readable SPDX metadata for all files and license texts in the LICENSES directory - A README file conforming to the Standard Readme Specification + A README file conforming to the Standard Readme Specification - Contributor Covenant Code of Conduct for participants + Contributor Covenant Code of Conduct for participants - CONTRIBUTING document outlining ways to contribute to this repository + CONTRIBUTING document outlining ways to contribute to this repository - Naming the primary branch of this repository main instead of master following modern best practices + Naming the primary branch of this repository main instead of master following modern best practices Structure of this report - After the “Introduction“ section, the D2.5 report begins with describing the requirements capture process we employed to enumerate key stakeholder types on WIF (“2 Requirements capture”). We defined and mapped various information needs to those stakeholders, and brainstormed 50+ possible dashboard features to meet those needs. This was narrowed down to 10 features by WIF for further development. - The next section (“3 Design and implementation”) describes an updated technical architecture of the project status dashboard based on input from WIF. This is so that all elements of the dashboard could be more easily integrated into, or implemented by, WIF for their platform. The new architecture splits the dashboard into two distinct components, the backend and the frontend. The backend handles data mining and processing the results into metrics to be visualised by the frontend. WIF has already used this deliverable to implement some features as their dashboard frontend, which are live on the WIF platform and will be rolled out to all users beginning September 2022. The WIF frontend is tied into the backend code in this deliverable. We have also developed a demonstration frontend tied to GitHub data and shows how the dashboard is platform agnostic and easily adaptable. - Next (“4 User feedback”), we describe the methodology and results of a survey for OSH practitioners to obtain feedback on the 10 features selected by WIF. This can prioritise the order in which WIF implements the frontend components of the the dashboard in a stepwise fashion. - Finally, the report describes in detail (“5 Step-by-step installation and use of sample dashboard implementations”) how to deploy the code of the data-mining backend and the demonstration frontend. There are also step-by-step usage instructions for the demo frontend with screenshots. - Requirements capture - An important milestone for WP2 was the month 18 proof-of-concept in D2.3 where we delivered a technical demonstrator that mines the metadata from various OSH repositories hosted on Wikifactory and GitHub. It calculates metrics related to the health of the projects and shows simple visualisations. This demonstrator puts into action the conceptual workflow of deriving and showing project status metrics. The fully open source code behind this initial proof-of-concept was published as part of D2.3. - To bring subsequent development into production in a way that directly impacts OSH projects and their repositories, we conducted a requirements capture process. This process was inspired by how product design specifications (PDS) are used in engineering methodology. Specifically, we wanted to identify and link specific features in the status dashboard to real OSH stakeholders and their needs. - This process began in Q3 2021, when we convened key partners within the OPEN_NEXT project for a series of online workshops for the requirements capture. These partners included three individuals from FHG representing WP3 and one from WIF. The goal was to narrow down a specific list of features and technical designs that will allow the dashboard to be implemented on the WIF platform for real users. + After the “Introduction“ section, the D2.5 report begins with describing the requirements capture process we employed to enumerate key stakeholder types on WIF (“2 Requirements capture”). We defined and mapped various information needs to those stakeholders, and brainstormed 50+ possible dashboard features to meet those needs. This was narrowed down to 10 features by WIF for further development. + The next section (“3 Design and implementation”) describes an updated technical architecture of the project status dashboard based on input from WIF. This is so that all elements of the dashboard could be more easily integrated into, or implemented by, WIF for their platform. The new architecture splits the dashboard into two distinct components, the backend and the frontend. The backend handles data mining and processing the results into metrics to be visualised by the frontend. WIF has already used this deliverable to implement some features as their dashboard frontend, which are live on the WIF platform and will be rolled out to all users beginning September 2022. The WIF frontend is tied into the backend code in this deliverable. We have also developed a demonstration frontend tied to GitHub data and shows how the dashboard is platform agnostic and easily adaptable. + Next (“4 User feedback”), we describe the methodology and results of a survey for OSH practitioners to obtain feedback on the 10 features selected by WIF. This can prioritise the order in which WIF implements the frontend components of the the dashboard in a stepwise fashion. + Finally, the report describes in detail (“5 Step-by-step installation and use of sample dashboard implementations”) how to deploy the code of the data-mining backend and the demonstration frontend. There are also step-by-step usage instructions for the demo frontend with screenshots. + Requirements capture + An important milestone for WP2 was the month 18 proof-of-concept in D2.3 where we delivered a technical demonstrator that mines the metadata from various OSH repositories hosted on Wikifactory and GitHub. It calculates metrics related to the health of the projects and shows simple visualisations. This demonstrator puts into action the conceptual workflow of deriving and showing project status metrics. The fully open source code behind this initial proof-of-concept was published as part of D2.3. + To bring subsequent development into production in a way that directly impacts OSH projects and their repositories, we conducted a requirements capture process. This process was inspired by how product design specifications (PDS) are used in engineering methodology. Specifically, we wanted to identify and link specific features in the status dashboard to real OSH stakeholders and their needs. + This process began in Q3 2021, when we convened key partners within the OPEN_NEXT project for a series of online workshops for the requirements capture. These partners included three individuals from FHG representing WP3 and one from WIF. The goal was to narrow down a specific list of features and technical designs that will allow the dashboard to be implemented on the WIF platform for real users. Stakeholder types and needs - The first step was to identify the key stakeholder types relevant to WIF and what their primary needs are. We enumerated nine stakeholder types based on the experience and input of WIF: Project owner, direct contributor, indirect developer, replicator, founder of similar project, researcher, recruiter, manufacturer, and educational user. Through the workshop with WIF and others in OPEN_NEXT, we grouped these stakeholders’ information needs from a status dashboard into: Activity level, community organisation, contributor profiles, documentation, popularity, newcomer friendliness. + The first step was to identify the key stakeholder types relevant to WIF and what their primary needs are. We enumerated nine stakeholder types based on the experience and input of WIF: Project owner, direct contributor, indirect developer, replicator, founder of similar project, researcher, recruiter, manufacturer, and educational user. Through the workshop with WIF and others in OPEN_NEXT, we grouped these stakeholders’ information needs from a status dashboard into: Activity level, community organisation, contributor profiles, documentation, popularity, newcomer friendliness. This is how each stakeholder type is defined: - Project owner: The primary maintainers of a project/repository on GitHub or WIF. Might want to understand how active their community is or want to support/nurture the community or look for contributors. + Project owner: The primary maintainers of a project/repository on GitHub or WIF. Might want to understand how active their community is or want to support/nurture the community or look for contributors. - Direct contributor: Someone looking to contribute to a project. Might want to know how alive the project is and if contributions are welcome and supported. + Direct contributor: Someone looking to contribute to a project. Might want to know how alive the project is and if contributions are welcome and supported. - Indirect developer: Someone looking for an existing project to replicate and tinker with. Might contribute to original project. + Indirect developer: Someone looking for an existing project to replicate and tinker with. Might contribute to original project. - Replicator: Someone who just wants to build an existing tool with little to no contribution. + Replicator: Someone who just wants to build an existing tool with little to no contribution. - Founder of similar project: People who are starting a similar open source hardware project. Someone who wants to understand what has already been done to learn from and reduce duplication of effort. + Founder of similar project: People who are starting a similar open source hardware project. Someone who wants to understand what has already been done to learn from and reduce duplication of effort. - Researcher: Typically someone from a company who wants to understand the state of the art. Could be for understanding competition or a project to build on. Or this could mean a “generic” researcher like an academic. + Researcher: Typically someone from a company who wants to understand the state of the art. Could be for understanding competition or a project to build on. Or this could mean a “generic” researcher like an academic. - Recruiter: Human resources (HR) person that wants to identify new hires from open source contributors. For now, this is more common in open source software. + Recruiter: Human resources (HR) person that wants to identify new hires from open source contributors. For now, this is more common in open source software. - Manufacturer: Organisations like fablabs who would like to provide manufacturing services as a business. + Manufacturer: Organisations like fablabs who would like to provide manufacturing services as a business. - Educational user: Those who contribute to, or use an existing OSH project as part of teaching or learning. Could be teacher and/or student. + Educational user: Those who contribute to, or use an existing OSH project as part of teaching or learning. Could be teacher and/or student. - This is how each information need is defined: + This is how each information need is defined: - Activity level: Is the project active, alive, or dead? And how has that changed over time? + Activity level: Is the project active, alive, or dead? And how has that changed over time? - Community organisation: Is this a solo or group project? How is the community organised and governed? + Community organisation: Is this a solo or group project? How is the community organised and governed? - Contributor profiles: What could be learned about the contributors to this project? + Contributor profiles: What could be learned about the contributors to this project? - Documentation: How complete is the documentation? This could be manufacturing metadata, reproducibility, license info, standards compliance, etc. + Documentation: How complete is the documentation? This could be manufacturing metadata, reproducibility, license info, standards compliance, etc. - Popularity: Is this project well-known, often-visited/accessed/downloaded, etc. + Popularity: Is this project well-known, often-visited/accessed/downloaded, etc. - Newcomer friendliness: Is it easy for a newcomer to start contributing to this project? + Newcomer friendliness: Is it easy for a newcomer to start contributing to this project? - Once these stakeholders and their information needs have been gathered, we organised them into a matrix showing the strengths of linkages between them (Table 1 below). The columns represent possible stakeholders for the T2.2 D2.5 dashboard; and rows represent different types of information about a project the stakeholders might need. We use “+”s (maximum two) to indicate the strength of association between stakeholders and their needs. - + Once these stakeholders and their information needs have been gathered, we organised them into a matrix showing the strengths of linkages between them (Table 1 below). The columns represent possible stakeholders for the T2.2 D2.5 dashboard; and rows represent different types of information about a project the stakeholders might need. We use “+”s (maximum two) to indicate the strength of association between stakeholders and their needs. + Table 1. Strength of associations (indicated by “+”s, maximum two) between stakeholders and their needs as exemplified on Wikifactory. @@ -9787,271 +9836,271 @@ - + Stakeholders → + ↓ Needs - Project owner + Project owner - Direct contributor + Direct contributor - Indirect developer + Indirect developer - Replicator + Replicator - Founder of similar project + Founder of similar project - Researcher + Researcher - Recruiter + Recruiter - Manufacturer + Manufacturer - Educational user + Educational user - Activity level + Activity level - ++ + ++ - ++ + ++ - + + + - + + + - + + + - + + + - + + + - + - + - Community organisation + Community organisation - ++ + ++ - + + + - + - + - + + + - + - + - + - + + + - Contributor profiles + Contributor profiles - + + + - + + + - + - + - + - + - ++ + ++ - + - + - Documentation + Documentation - ++ + ++ - ++ + ++ - ++ + ++ - ++ + ++ - + + + - + + + - + + + - ++ + ++ - ++ + ++ - Popularity + Popularity - ++ + ++ - + - + + + - + - + - + + + - + - + + + - + - Newcomer friendliness + Newcomer friendliness - ++ + ++ - ++ + ++ - + + + - + - + - + - + - + - ++ + ++ - - Table 1. Strength of associations (indicated by “+”s, maximum two) between stakeholders and their needs as exemplified on Wikifactory. - Mapping information needs to specific features - We then brainstormed 51 specific features that could be implemented in the status dashboard, and linked them to the stakeholder information needs (Table 2 in the Annexsection). Columns represent information needs of the T2.2 dashboard; and the rows are specific features that the dashboard could implement to fulfil those needs. A “+” indicates a clear relationship. This table is meant to help prioritise which features to work on. Items in bold were prioritised during the requirements capture exercise. Each feature was carefully defined for all of us to share the same understanding (Table 3 in Annexsection). + + Mapping information needs to specific features + We then brainstormed 51 specific features that could be implemented in the status dashboard, and linked them to the stakeholder information needs (Table 2 in the Annexsection). Columns represent information needs of the T2.2 dashboard; and the rows are specific features that the dashboard could implement to fulfil those needs. A “+” indicates a clear relationship. This table is meant to help prioritise which features to work on. Items in bold were prioritised during the requirements capture exercise. Each feature was carefully defined for all of us to share the same understanding (Table 3 in Annexsection). Feature prioritisation - It was not practical to implement all 51 dashboard features within the constraints of the OPEN_NEXT project. Therefore, with the information gathered above in mind, each partner in the workshop was asked to list the top 10 features that they thought were most important to implement for maximum impact. These features all summarise key information about various aspects of an open source hardware project and could, for example, be part of a project page on WIF. Then, WIF used this information to decide on their 10 top features, which are as follows (including explanations of each): + It was not practical to implement all 51 dashboard features within the constraints of the OPEN_NEXT project. Therefore, with the information gathered above in mind, each partner in the workshop was asked to list the top 10 features that they thought were most important to implement for maximum impact. These features all summarise key information about various aspects of an open source hardware project and could, for example, be part of a project page on WIF. Then, WIF used this information to decide on their 10 top features, which are as follows (including explanations of each): - File types: Classify files into "mechanical/electrical/software/documentation" and by proportion. + File types: Classify files into "mechanical/electrical/software/documentation" and by proportion. - Issue activity level: Graph of issue activities (open/close/comments) over time. + Issue activity level: Graph of issue activities (open/close/comments) over time. - Commits over time: Graph of commits over time. + Commits over time: Graph of commits over time. - User skill tags/profile: Show skill-related tags for a user, probably from the ontology. + User skill tags/profile: Show skill-related tags for a user, probably from the ontology. - Project skill tags/profile: Show skill-related tags for a project, probably from the ontology. + Project skill tags/profile: Show skill-related tags for a project, probably from the ontology. - Manufacturing metadata: Display what’s needed for manufacture like “Need 3D printing, PCB fabrication”. + Manufacturing metadata: Display what’s needed for manufacture like “Need 3D printing, PCB fabrication”. - Standards compliance metadata: REUSE, Standard README, DIN-SPEC 3105-1, OKH, OSHWA, or technology readiness levels like OTRL/ODRL. + Standards compliance metadata: REUSE, Standard README, DIN-SPEC 3105-1, OKH, OSHWA, or technology readiness levels like OTRL/ODRL. - LICENSE file and meanings: Not just which license, but also what type (i.e. CC-licenses, software licenses, or hardware licenses), what it means for the hardware and if it meets certain standards. Info on if it’s a reciprocal or non-reciprocal license. + LICENSE file and meanings: Not just which license, but also what type (i.e. CC-licenses, software licenses, or hardware licenses), what it means for the hardware and if it meets certain standards. Info on if it’s a reciprocal or non-reciprocal license. - Files editability: Are editable are the files in this repository? E.g. “PDF vs editable CAD files”. + Files editability: Are editable are the files in this repository? E.g. “PDF vs editable CAD files”. - Different views for different stakeholders: For example, there could be a project owner view that shows a different set of metrics than a visitor view; or a view meant to be embedded on a WIF page. + Different views for different stakeholders: For example, there could be a project owner view that shows a different set of metrics than a visitor view; or a view meant to be embedded on a WIF page. - These 10 features fed into the planning of the development of the project status dashboard for D2.5. Additionally, WIF provided feedback on how the technical infrastructure of the dashboard could be improved. This would ease the real-world use case of integrating this infrastructure into production on the WIF platform. This will be described in the next section. + These 10 features fed into the planning of the development of the project status dashboard for D2.5. Additionally, WIF provided feedback on how the technical infrastructure of the dashboard could be improved. This would ease the real-world use case of integrating this infrastructure into production on the WIF platform. This will be described in the next section. Design and implementation - With feedback and input from WIF, we re-architected the entire technical infrastructure of the project status dashboard relative to D2.3: there is now a distinct backend and a frontend which can be independently implemented (Figure 1). The backend can access OSH project repositories hosted on WIF and GitHub; the frontend is delivered in two versions: one is an example demonstrating core features, the other is integrated into the WIF platform. - + With feedback and input from WIF, we re-architected the entire technical infrastructure of the project status dashboard relative to D2.3: there is now a distinct backend and a frontend which can be independently implemented (Figure 1). The backend can access OSH project repositories hosted on WIF and GitHub; the frontend is delivered in two versions: one is an example demonstrating core features, the other is integrated into the WIF platform. + iVBORw0KGgoAAAANSUhEUgAAA2MAAAFdCAYAAAH52YVrAAAACXBIWXMAAA7DAAAOwwHHb6hk AAAAGXRFWHRTb2Z0d2FyZQB3d3cuaW5rc2NhcGUub3Jnm+48GgAAABV0RVh0QXV0aG9yAFBl bi1ZdWFuIEhzaW5nxrtGrgAAAFJ0RVh0Q29weXJpZ2h0AENDIEF0dHJpYnV0aW9uLVNoYXJl @@ -10587,16 +10636,16 @@ AABJRU5ErkJggg== - Figure 1. Final technical architecture for the D2.5 project status dashboard. - Here is a summary of what they do: - The backend is the “behind the scenes” application programming interface (API) hosted on a web server. This API uses representational state transfer (REST) model for data communication, and receives requests for project status metrics (such as those in the list of features defined in the previous section) regarding a specific OSH project repository hosted on WIF or GitHub. This backend will then query the WIF or GitHub APIs to obtain raw metadata about said repository, calculate the metrics, and return the results. For example, if we send a request for file type information about the GitHub repository https://github.com/mathewlippincott/airpup-balloon to the backend (AirPup is a successful open source kite balloon for aerial remote sensing), it will ask for relevant raw metadata from GitHub, calculate information such as the editability of the various files in the repository, and return this derived data. The same functionality has been implemented for projects hosted on WIF. We have delivered this backend in D2.5 in a way that can be directly used by WIF to improve their offering. - The frontend is a user-facing web interface that makes API calls to the backend and visualises the information from the backend. D2.5 includes a demo frontend as a technical demonstrator of the capabilities, which shows information from GitHub repositories. The key goal of this demonstrator is to show that the dashboard technical stack is adaptable to platforms beyond WIF. - The backend and frontends can be implemented and hosted separately, and on different servers. Hosting platforms such as WIF, GitHub, or individual OSH projects could create their own frontends, and tie them into the backend developed for D2.5. Two versions demonstrating the frontend are delivered in D2.5: One is an example frontend to show how one could be made, and the next sub-section describes how WIF has implemented it. - The install and usage of these components will be described in more detail in the section “ 5Step-by-step installation and use of sample dashboard implementations”. + Figure 1. Final technical architecture for the D2.5 project status dashboard. + Here is a summary of what they do: + The backend is the “behind the scenes” application programming interface (API) hosted on a web server. This API uses representational state transfer (REST) model for data communication, and receives requests for project status metrics (such as those in the list of features defined in the previous section) regarding a specific OSH project repository hosted on WIF or GitHub. This backend will then query the WIF or GitHub APIs to obtain raw metadata about said repository, calculate the metrics, and return the results. For example, if we send a request for file type information about the GitHub repository https://github.com/mathewlippincott/airpup-balloon to the backend (AirPup is a successful open source kite balloon for aerial remote sensing), it will ask for relevant raw metadata from GitHub, calculate information such as the editability of the various files in the repository, and return this derived data. The same functionality has been implemented for projects hosted on WIF. We have delivered this backend in D2.5 in a way that can be directly used by WIF to improve their offering. + The frontend is a user-facing web interface that makes API calls to the backend and visualises the information from the backend. D2.5 includes a demo frontend as a technical demonstrator of the capabilities, which shows information from GitHub repositories. The key goal of this demonstrator is to show that the dashboard technical stack is adaptable to platforms beyond WIF. + The backend and frontends can be implemented and hosted separately, and on different servers. Hosting platforms such as WIF, GitHub, or individual OSH projects could create their own frontends, and tie them into the backend developed for D2.5. Two versions demonstrating the frontend are delivered in D2.5: One is an example frontend to show how one could be made, and the next sub-section describes how WIF has implemented it. + The install and usage of these components will be described in more detail in the section “ 5Step-by-step installation and use of sample dashboard implementations”. WIF implementation of dashboard frontend - To deliver real-world business value and positive impact for the wider OSH community, a key goal of D2.5 is for features of the project status dashboard to be accessible to real users, realised as an integrated add-on to the WIF platform. To this end, and with our developmental and research support, WIF has implemented a dashboard frontend on their platform. This frontend is integrated into the WIF project page, and is tied into the D2.5 backend. - As previously discussed, WIF identified 10 high priority features to be implemented in this dashboard. Two of those were first built into the WIF platform based on WIF’s desire, and visible on a subset of project pages. These are: (a) an indicator of license information providing a breakdown of license permissions, limitations, and conditions on a WIF project page (Figure 2); and (b) a visual breakdown of file types in the project (Figure 3). These features are now working, and the stated plan of WIF is to gradually roll them out to users beginning September 2022. - + To deliver real-world business value and positive impact for the wider OSH community, a key goal of D2.5 is for features of the project status dashboard to be accessible to real users, realised as an integrated add-on to the WIF platform. To this end, and with our developmental and research support, WIF has implemented a dashboard frontend on their platform. This frontend is integrated into the WIF project page, and is tied into the D2.5 backend. + As previously discussed, WIF identified 10 high priority features to be implemented in this dashboard. Two of those were first built into the WIF platform based on WIF’s desire, and visible on a subset of project pages. These are: (a) an indicator of license information providing a breakdown of license permissions, limitations, and conditions on a WIF project page (Figure 2); and (b) a visual breakdown of file types in the project (Figure 3). These features are now working, and the stated plan of WIF is to gradually roll them out to users beginning September 2022. + /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR @@ -12110,8 +12159,8 @@ KdijFADcUYp2KMUANxRinYoxQA3FGKdijFADcUYp2KMUANxRinYoxQA3FFOxRQB//9k= - Figure 2. License information component of the dashboard frontend delivered in D2.5. - + Figure 2. License information component of the dashboard frontend delivered in D2.5. + /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR @@ -13232,31 +13281,31 @@ YoAbijFOxRigBuKMU7FGKAG4oxTsUYoAbijFOxRigBuKMU7FGKAG4oxTsUYoAbiinYooA//Z - Figure 3. Dashboard element showing breakdown of file types in the project. - User feedback - In order for WIF to continue integrating the results of D2.5 in their future work, we attempted the collection of feedback from real OSH practitioners to help prioritise the order in which the remaining eight out of 10 features should be developed in the frontend by WIF. - This feedback and validation were actioned through the development and deployment of an online survey. The rest of this section will describe the design of the survey (4.1), where and how it was distributed (4.2), and a discussion of the main learnings from it (4.3). + Figure 3. Dashboard element showing breakdown of file types in the project. + User feedback + In order for WIF to continue integrating the results of D2.5 in their future work, we attempted the collection of feedback from real OSH practitioners to help prioritise the order in which the remaining eight out of 10 features should be developed in the frontend by WIF. + This feedback and validation were actioned through the development and deployment of an online survey. The rest of this section will describe the design of the survey (4.1), where and how it was distributed (4.2), and a discussion of the main learnings from it (4.3). Survey design The structure of the survey is comprised of the following: - Very short introductory paragraph that frames the survey as getting feedback on which dashboard frontend features are desired, in particular on WIF. To safeguard the privacy of respondents and remain compliant with relevant policies, the rules described in OPEN_NEXT D7.1 and D7.2. The full informed consent document that respondents could view is included with this report in “consent information.fodt”. + Very short introductory paragraph that frames the survey as getting feedback on which dashboard frontend features are desired, in particular on WIF. To safeguard the privacy of respondents and remain compliant with relevant policies, the rules described in OPEN_NEXT D7.1 and D7.2. The full informed consent document that respondents could view is included with this report in “consent information.fodt”. - Present each dashboard feature with a screenshot, followed by numerical scoring and a text box for any additional feedback. + Present each dashboard feature with a screenshot, followed by numerical scoring and a text box for any additional feedback. - A drag-and-drop activity for the respondent to rank the features in descending priority. + A drag-and-drop activity for the respondent to rank the features in descending priority. - Additional space for more feedback on any aspect of the survey. + Additional space for more feedback on any aspect of the survey. - As question asking if the respondent would like to receive named attribution in resulting reports such as this one. + As question asking if the respondent would like to receive named attribution in resulting reports such as this one. - For step 3 in the structure, the survey is shown as a series of screens, each one showing a screenshot or mockup of a dashboard feature (Figure 4). From top column down, left to right: License information, file types breakdown, files editability breakdown, commit activity history, issues activity history, manufacturing metadata, project skills tags, standards compliance metadata, user skills tags. Under that image a slider was provided to assign a numerical rating from 0 to 5 (with 5 being most important) and a freeform text box for additional feedback. - + For step 3 in the structure, the survey is shown as a series of screens, each one showing a screenshot or mockup of a dashboard feature (Figure 4). From top column down, left to right: License information, file types breakdown, files editability breakdown, commit activity history, issues activity history, manufacturing metadata, project skills tags, standards compliance metadata, user skills tags. Under that image a slider was provided to assign a numerical rating from 0 to 5 (with 5 being most important) and a freeform text box for additional feedback. + /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoM DAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsN FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wgAR @@ -18441,10 +18490,10 @@ hyNS07XUPBbFJ8Eax9CRVAWTYaNFH+R//9k= - Figure 4. Images of dashboard frontend features with labels under each. - The survey was implemented on the fully open source EUSurvey platform2 - https://ec.europa.eu/eusurvey/ which is developed and hosted by the European Commission (Figure 5). The full content of the survey has been archived in the file “survey-files/D2.5 dashboard EUSurvey.zip”. - + Figure 4. Images of dashboard frontend features with labels under each. + The survey was implemented on the fully open source EUSurvey platform2 + https://ec.europa.eu/eusurvey/ which is developed and hosted by the European Commission (Figure 5). The full content of the survey has been archived in the file “survey-files/D2.5 dashboard EUSurvey.zip”. + /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR @@ -19928,271 +19977,271 @@ gAooooAKKKKACiiigAooooA//9k= - Figure 5. Screenshot from a typical page of the dashboard survey. + Figure 5. Screenshot from a typical page of the dashboard survey. Survey deployment The survey was disseminated in three ways. - First, we coordinated with WP3 to include a session for the dashboard during the D3.5 validation day on 27 May 2022. This day was an intensive virtual workshop where OSH practitioners were invited to provide feedback on the ICT tools developed as part of WP3. Because implementations of the D2.5 dashboard frontend would also be used by the same practitioners, we coordinated the event so that we could also obtain feedback on the dashboard. During the session, participants were shown and given verbal descriptions of each dashboard feature as shown in the survey, and provided their feedback directly in the survey. There were four people present during this validation day, and the details about the whole event are reported in D3.5 “Finalised demonstrators - usability-tested, verified and validated demonstrators”. - The second venue for the survey was direct invitations to WIF users to complete the survey. Instead of sending the survey to all WIF users, we wanted to focus on those who have managed or contributed to OSH projects relatively recently. That is, projects which are currently active whilst at the same time being mature enough to clearly see the relevance of the particular dashboard features proposed. - To achieve this, we started with projects listed on the WIF projects page3 - https://wikifactory.com/contribute/projects as of 31 March 2022. Within this, we took the top 50 projects from each of the following four filter categories: recent activity, number of followers, number of contributions, number of views. We filtered for projects that appeared in more than one of these categories while meeting the following criteria: uses open source licenses meeting the open source hardware definition4 - https://www.oshwa.org/definition/, has both contributions and design files in the public-facing project, and has some activity within the past 12 months. This gave us a list of 27 unique user names responsible for 44 WIF projects (one was excluded because it was a project run by WIF). The difference between the two numbers is because a single user might manage multiple projects hosted on WIF. This list of 27 users were the ones we invited to the survey. - To minimise the circulation of the contact information of these users, we asked WIF (who have contact emails in their database) to send the invitations. There was a follow up email approximately four days after the initial invitation to remind the 27 users to respond. + First, we coordinated with WP3 to include a session for the dashboard during the D3.5 validation day on 27 May 2022. This day was an intensive virtual workshop where OSH practitioners were invited to provide feedback on the ICT tools developed as part of WP3. Because implementations of the D2.5 dashboard frontend would also be used by the same practitioners, we coordinated the event so that we could also obtain feedback on the dashboard. During the session, participants were shown and given verbal descriptions of each dashboard feature as shown in the survey, and provided their feedback directly in the survey. There were four people present during this validation day, and the details about the whole event are reported in D3.5 “Finalised demonstrators - usability-tested, verified and validated demonstrators”. + The second venue for the survey was direct invitations to WIF users to complete the survey. Instead of sending the survey to all WIF users, we wanted to focus on those who have managed or contributed to OSH projects relatively recently. That is, projects which are currently active whilst at the same time being mature enough to clearly see the relevance of the particular dashboard features proposed. + To achieve this, we started with projects listed on the WIF projects page3 + https://wikifactory.com/contribute/projects as of 31 March 2022. Within this, we took the top 50 projects from each of the following four filter categories: recent activity, number of followers, number of contributions, number of views. We filtered for projects that appeared in more than one of these categories while meeting the following criteria: uses open source licenses meeting the open source hardware definition4 + https://www.oshwa.org/definition/, has both contributions and design files in the public-facing project, and has some activity within the past 12 months. This gave us a list of 27 unique user names responsible for 44 WIF projects (one was excluded because it was a project run by WIF). The difference between the two numbers is because a single user might manage multiple projects hosted on WIF. This list of 27 users were the ones we invited to the survey. + To minimise the circulation of the contact information of these users, we asked WIF (who have contact emails in their database) to send the invitations. There was a follow up email approximately four days after the initial invitation to remind the 27 users to respond. Third, the survey was sent – among others developed by WP3 – to OSH practitioners among various communities that WP3 is in contact with. This included (total 543): - 118 from the OPEN_NEXT consortium and demonstrators + 118 from the OPEN_NEXT consortium and demonstrators - 406 from Open Source Ecology Germany including FabCity Hamburg + 406 from Open Source Ecology Germany including FabCity Hamburg - 19 from interviewees for D3.1 + 19 from interviewees for D3.1 - The consent information given to respondents is in the file “survey-files/consent information.fodt”. + The consent information given to respondents is in the file “survey-files/consent information.fodt”. Results and discussion - Through the three venues to which we have disseminated the survey, we received seven complete responses. It was difficult to conduct a deep quantitative analysis of the results, but the ranked average numerical ratings for each feature are as follows (rounded to two decimal points, higher numbers (maximum 5.00) corresponds to stronger perceived usefulness by the respondents): + Through the three venues to which we have disseminated the survey, we received seven complete responses. It was difficult to conduct a deep quantitative analysis of the results, but the ranked average numerical ratings for each feature are as follows (rounded to two decimal points, higher numbers (maximum 5.00) corresponds to stronger perceived usefulness by the respondents): - LICENSE file and meanings: 4.86 + LICENSE file and meanings: 4.86 - Manufacturing metadata: 4.43 + Manufacturing metadata: 4.43 - Project skill tags/profile: 4.14 + Project skill tags/profile: 4.14 - Standards compliance metadata: 3.71 + Standards compliance metadata: 3.71 - Issue activity level: 3.57 + Issue activity level: 3.57 - Commits over time: 3.57 + Commits over time: 3.57 - User skill tags/profile: 3.57 + User skill tags/profile: 3.57 - Files editability: 3.43 + Files editability: 3.43 - File types: 3.43 + File types: 3.43 - As reported in the section “3.1 WIF implementation of dashboard frontend”, WIF has implemented the license information and file types breakdown within the frontend (i.e. project pages). The former is the highest rated feature from the survey. This makes sense as OSH practitioners need to know whether a project meets the open source hardware definition5 - https://www.oshwa.org/definition/ before making use of it. - The survey results from D2.5 are also useful for WIF as they continue to implement dashboard features on their platform. They could do so in a stepwise fashion starting with the highest scoring features. - Relatively few written comments were included with the scores. These comments mostly affirmed the scores in a qualitative way. For example, to paraphrase one comment regarding scoring showing skills tags highly: “Lets me know if I could help projects that I like / find interesting, with skills that I have…” Also, the final ranking at the end of the survey largely corresponds with the individual scores, though it seems that some respondents might have not ranked every single feature in that question. - The response rate 1.2% (seven responses from 574 people across the three venues to which we distributed the survey) is not especially high, but is within the reasonable range of online surveys in general. Importantly, we were drawing from a fairly narrow pool of potential respondents. For example, there are more than 130,000 registered users on WIF as of mid-2022, but only 27 met our selection criteria who have been active on an OSH project within the past 12 months. In addition, OSH as a field is not as mature as open source software and therefore there may be considerably fewer practitioners to draw from who have the experience to provide in-depth feedback. For these reasons, we believe D2.5 is an important pioneering effort, and both the survey and frontend implementations will become even more relevant along with other ICT tools developed through OPEN_NEXT. - Full anonymised responses are included in the attached spreadsheet “survey-files/dashboard-survey-results.fods”. - Step-by-step installation and use of sample dashboard implementations + As reported in the section “3.1 WIF implementation of dashboard frontend”, WIF has implemented the license information and file types breakdown within the frontend (i.e. project pages). The former is the highest rated feature from the survey. This makes sense as OSH practitioners need to know whether a project meets the open source hardware definition5 + https://www.oshwa.org/definition/ before making use of it. + The survey results from D2.5 are also useful for WIF as they continue to implement dashboard features on their platform. They could do so in a stepwise fashion starting with the highest scoring features. + Relatively few written comments were included with the scores. These comments mostly affirmed the scores in a qualitative way. For example, to paraphrase one comment regarding scoring showing skills tags highly: “Lets me know if I could help projects that I like / find interesting, with skills that I have…” Also, the final ranking at the end of the survey largely corresponds with the individual scores, though it seems that some respondents might have not ranked every single feature in that question. + The response rate 1.2% (seven responses from 574 people across the three venues to which we distributed the survey) is not especially high, but is within the reasonable range of online surveys in general. Importantly, we were drawing from a fairly narrow pool of potential respondents. For example, there are more than 130,000 registered users on WIF as of mid-2022, but only 27 met our selection criteria who have been active on an OSH project within the past 12 months. In addition, OSH as a field is not as mature as open source software and therefore there may be considerably fewer practitioners to draw from who have the experience to provide in-depth feedback. For these reasons, we believe D2.5 is an important pioneering effort, and both the survey and frontend implementations will become even more relevant along with other ICT tools developed through OPEN_NEXT. + Full anonymised responses are included in the attached spreadsheet “survey-files/dashboard-survey-results.fods”. + Step-by-step installation and use of sample dashboard implementations Backend - This section assumes knowledge of Python, Git, and using a GNU/Linux-based server including installing software from package managers and running a terminal session. - Note: This software is designed to be deployed on a server by system administrators or developers, not on generic consumer devices. A demo API which can be programmatically accessed is available here: https://wp22dev.fly.dev/data/ - This project requires Python version 3.10 or later on your server and running it in a Python virtual environment is optional but recommended. Detailed external library dependencies are listed in the standard-conformant requirements.txt file and also here: + This section assumes knowledge of Python, Git, and using a GNU/Linux-based server including installing software from package managers and running a terminal session. + Note: This software is designed to be deployed on a server by system administrators or developers, not on generic consumer devices. A demo API which can be programmatically accessed is available here: https://wp22dev.fly.dev/data/ + This project requires Python version 3.10 or later on your server and running it in a Python virtual environment is optional but recommended. Detailed external library dependencies are listed in the standard-conformant requirements.txt file and also here: - aiohttp>=3.8.1 + aiohttp>=3.8.1 - fastapi>=0.70 + fastapi>=0.70 - gql>=3.0.0 + gql>=3.0.0 - PyYAML>=5.4 + PyYAML>=5.4 - requests>=2.28 + requests>=2.28 - uvicorn>=0.15 + uvicorn>=0.15 In addition to Python and the dependencies listed above, the following programs must be installed and accessible from the command line: - git (version 2.7.4 or later) + git (version 2.7.4 or later) - pip (version 19.3.1 or later) + pip (version 19.3.1 or later) - A GitHub personal access token is required to be available as an environmental variable. This is because the Python scripts will use it for GitHub API queries. This token is an alphanumeric string in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. - Running from source - The code can be run from source and has been tested on updated versions of GNU/Linux server operating systems including Red Hat Enterprise Linux 8.7. While effort has been made to keep the Python scripts platform-agnostic, they have not been tested under other operating systems such as BSD-derivatives, Apple macOS or Microsoft Windows as they - especially the latter two - are rarely used for hosting code such as this. - On your server, with the tools git and pip installed, run the following commands in a terminal session to retrieve the latest version of this repository and prepare it for development and running locally (usually for testing): - git clone https://github.com/OPEN-NEXT/wp2.2_dev.git - pip install --user -r requirements.txt - The git command will download the files in this repository onto your server into a directory named wp2.2_dev, and pip installs the Python dependencies listed in requirements.txt. - In a terminal window at the root directory of this repository, start the server with the uvicorn Asynchronous Server Gateway Interface (ASGI) server by running this command: - uvicorn oshminer.main:app --reload + A GitHub personal access token is required to be available as an environmental variable. This is because the Python scripts will use it for GitHub API queries. This token is an alphanumeric string in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. + Running from source + The code can be run from source and has been tested on updated versions of GNU/Linux server operating systems including Red Hat Enterprise Linux 8.7. While effort has been made to keep the Python scripts platform-agnostic, they have not been tested under other operating systems such as BSD-derivatives, Apple macOS or Microsoft Windows as they - especially the latter two - are rarely used for hosting code such as this. + On your server, with the tools git and pip installed, run the following commands in a terminal session to retrieve the latest version of this repository and prepare it for development and running locally (usually for testing): + git clone https://github.com/OPEN-NEXT/wp2.2_dev.git + pip install --user -r requirements.txt + The git command will download the files in this repository onto your server into a directory named wp2.2_dev, and pip installs the Python dependencies listed in requirements.txt. + In a terminal window at the root directory of this repository, start the server with the uvicorn Asynchronous Server Gateway Interface (ASGI) server by running this command: + uvicorn oshminer.main:app --reload There will be some commandline output which ends with the following line: - INFO: Application startup complete. + INFO: Application startup complete. This means the server API is up an running, and should be accessible on your local machine on port 8000 at 127.0.0.1. - Deploy as container - There is a Dockerfile in this repository that defines a container within which this code can run. - To build and use the container, you need to have programs like Podman or Docker installed. + Deploy as container + There is a Dockerfile in this repository that defines a container within which this code can run. + To build and use the container, you need to have programs like Podman or Docker installed. With the repository cloned by git onto your system, navigate to it and build the container with this command: - podman build -t wp22dev ./ --format=docker - Replace the command podman with docker depending on which one is available (this project has been tested with Podman 4.0.2), and wp22dev can be replaced with any other name. --format=docker is needed to explicitly build this as a Docker-formatted container that will be accepted by cloud services like Heroku. + podman build -t wp22dev ./ --format=docker + Replace the command podman with docker depending on which one is available (this project has been tested with Podman 4.0.2), and wp22dev can be replaced with any other name. --format=docker is needed to explicitly build this as a Docker-formatted container that will be accepted by cloud services like Heroku. Then, the run the container on port 8000 at 127.0.0.1 with this command: - podman run --env PORT=8000 --env GITHUB_TOKEN=[token] -p 127.0.0.1:8000:8000 -d wp22dev - Where token is the 40 character alphanumeric string of your GitHub API personal access token. It is in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. + podman run --env PORT=8000 --env GITHUB_TOKEN=[token] -p 127.0.0.1:8000:8000 -d wp22dev + Where token is the 40 character alphanumeric string of your GitHub API personal access token. It is in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. Heroku deployment example - The image built this way can be pushed to cloud hosting providers such as Heroku. With Heroku as an example: + The image built this way can be pushed to cloud hosting providers such as Heroku. With Heroku as an example: - Set up an empty app from your Heroku dashboard. + Set up an empty app from your Heroku dashboard. - In the Settings page for your Heroku app, set a Config Var with Key “GITHUB_TOKEN” and Value being your GitHub API personal access token. + In the Settings page for your Heroku app, set a Config Var with Key “GITHUB_TOKEN” and Value being your GitHub API personal access token. - With the Heroku commandline interface installed, first login from your terminal: + With the Heroku commandline interface installed, first login from your terminal: - heroku container:login + heroku container:login - Push the container image built above to your Heroku app: + Push the container image built above to your Heroku app: - podman push wp22dev registry.heroku.com/[your app name]/web + podman push wp22dev registry.heroku.com/[your app name]/web - Release the pushed container into production: + Release the pushed container into production: - heroku container:release web --app=[your app name] + heroku container:release web --app=[your app name] Fly.io example - Similar to Heroku, the container image created above can be deployed to an app on Fly.io. Assuming a Fly.io account has already been created: + Similar to Heroku, the container image created above can be deployed to an app on Fly.io. Assuming a Fly.io account has already been created: - Log in to Fly.io in a terminal session: + Log in to Fly.io in a terminal session: - flyctl auth login + flyctl auth login - Launch a new app. Run the following command, which will ask for an app name. Enter [your app name] when prompted, replacing it with whatever name you’d like: + Launch a new app. Run the following command, which will ask for an app name. Enter [your app name] when prompted, replacing it with whatever name you’d like: - flyctl launch + flyctl launch - Authorise pushing a container image to the Fly.io image registry: + Authorise pushing a container image to the Fly.io image registry: - flyctl auth docker + flyctl auth docker - Push the locally built image to the remote Fly.io image registry: + Push the locally built image to the remote Fly.io image registry: - podman push wp22dev registry.fly.io/[your app name] + podman push wp22dev registry.fly.io/[your app name] - Deploy the app: + Deploy the app: - flyctl deploy --image registry.fly.io/[your app name] + flyctl deploy --image registry.fly.io/[your app name] - Set GitHub API personal access token as environmental variable: + Set GitHub API personal access token as environmental variable: - flyctl secrets set GITHUB_TOKEN=[token] - Where token is the 40 character alphanumeric string of your GitHub API personal access token. It is in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. - A demo of this is hosted on Fly.io with this API endpoint: - https://wp22dev.fly.dev/data - This demo instance will go into a sleep state after a period of inactivity (approximately 30 minutes at time of writing). If your API calls to this endpoint is taking more than a few seconds, it might be the demo waking from that state. - Usage + flyctl secrets set GITHUB_TOKEN=[token] + Where token is the 40 character alphanumeric string of your GitHub API personal access token. It is in the form of “ghp_2D5TYFikFsQ4U9KPfzHyvigMycePCPqkPgWc”. + A demo of this is hosted on Fly.io with this API endpoint: + https://wp22dev.fly.dev/data + This demo instance will go into a sleep state after a period of inactivity (approximately 30 minutes at time of writing). If your API calls to this endpoint is taking more than a few seconds, it might be the demo waking from that state. + Backend usage The backend server listens to requests for information about a list of open source hardware (and software) repositories hosted on WIF or GitHub. - Making requests to the REST API - GET requests to the API are formed as JSON payloads to the /data endpoint. There are two components to each request: + Making requests to the REST API + GET requests to the API are formed as JSON payloads to the /data endpoint. There are two components to each request: - repo_urls: An array of strings of repository URLs, such as https://wikifactory.com/+elektricworks/pikon-telescope. Currently, metadata retrieval for WIF project and GitHub repository URLs are implemented. Each URL is composed of the WIF domain (wikifactory.com), space (e.g. +elektricworks), and project (e.g. pikon-telescope). + repo_urls: An array of strings of repository URLs, such as https://wikifactory.com/+elektricworks/pikon-telescope. Currently, metadata retrieval for WIF project and GitHub repository URLs are implemented. Each URL is composed of the WIF domain (wikifactory.com), space (e.g. +elektricworks), and project (e.g. pikon-telescope). - requested_data: An array of strings representing the types of repository metrics desired for each repository. Currently, the following are implemented for WIF projects: + requested_data: An array of strings representing the types of repository metrics desired for each repository. Currently, the following are implemented for WIF projects: - files_info: The numbers and proportions of mechanical and electronic computer-assisted design (CAD), image, data, document, and other file types in the repository. The list of file types was derived from the open source hardware paper published by Bonvoisin et al. (2018)6 - Bonvoisin, J., Buchert, T., Preidel, M., & Stark, R. G. (2018). How participative is open source hardware? Insights from online repository mining. Design Science, 4(e19). https://doi.org/10.1017/dsj.2018.15. + files_info: The numbers and proportions of mechanical and electronic computer-assisted design (CAD), image, data, document, and other file types in the repository. The list of file types was derived from the open source hardware paper published by Bonvoisin et al. (2018)6 + Bonvoisin, J., Buchert, T., Preidel, M., & Stark, R. G. (2018). How participative is open source hardware? Insights from online repository mining. Design Science, 4(e19). https://doi.org/10.1017/dsj.2018.15. - files_editability: Basic information about how “editable” the CAD files are in this repository, based on a file extensions list by Open Source Ecology Germany7 - https://gitlab.com/OSEGermany/osh-file-types/. + files_editability: Basic information about how “editable” the CAD files are in this repository, based on a file extensions list by Open Source Ecology Germany7 + https://gitlab.com/OSEGermany/osh-file-types/. - license: The license for the repository. + license: The license for the repository. - tags: Aggregated tags for the repository and any associated with the maintainers of that repository. + tags: Aggregated tags for the repository and any associated with the maintainers of that repository. - commits_level: The hash identifier (contribution id for WIF projects) and timestamp of each commit to the repository. This can be used to graph the commit activity level in a frontend visualisation. Note: This will be based on commits from the first three detected branches in the repository, including the default branch. This is because the time it takes to requests commits across various branches take a long time, and APIs might time out. Also note that WIF projects do not have branches, so it will behave as if there is only one branch. + commits_level: The hash identifier (contribution id for WIF projects) and timestamp of each commit to the repository. This can be used to graph the commit activity level in a frontend visualisation. Note: This will be based on commits from the first three detected branches in the repository, including the default branch. This is because the time it takes to requests commits across various branches take a long time, and APIs might time out. Also note that WIF projects do not have branches, so it will behave as if there is only one branch. - issues_level: Similar to commits_level, but for all issues in the repository. + issues_level: Similar to commits_level, but for all issues in the repository. The following is an example request that could be sent to the API for three WIF projects: - { - "repo_urls": [ - "https://wikifactory.com/+dronecoria/dronecoria-frame", - "https://wikifactory.com/@luzleanne/community-composter", - "https://wikifactory.com/+elektricworks/pikon-telescope" - ], - "requested_data": [ - "files_info", - "files_editability", - "license", - "tags", - "commits_level", - "issues_level" - ] - } - API response format + { + "repo_urls": [ + "https://wikifactory.com/+dronecoria/dronecoria-frame", + "https://wikifactory.com/@luzleanne/community-composter", + "https://wikifactory.com/+elektricworks/pikon-telescope" + ], + "requested_data": [ + "files_info", + "files_editability", + "license", + "tags", + "commits_level", + "issues_level" + ] + } + API response format The API will respond with a JSON array containing the requested_data for each repository in repo_urls. - JSON is a highly hierarchical organisation of structured data. Specifically, for each repository, the JSON response will include (bullet point level corresponds to the hierarchy in the JSON response): + JSON is a highly hierarchical organisation of structured data. Specifically, for each repository, the JSON response will include (bullet point level corresponds to the hierarchy in the JSON response): - repository: String containing the repository URL. + repository: String containing the repository URL. - platform: String of either “Wikifactory” or “GitHub”. + platform: String of either “Wikifactory” or “GitHub”. - requested_data: Object containing the following: + requested_data: Object containing the following: - + - files_editability: Object containing the following: + files_editability: Object containing the following: - + - files_count: Integer number of (presumed to be) CAD files that are not text documents or data files (like CSV). + files_count: Integer number of (presumed to be) CAD files that are not text documents or data files (like CSV). - files_openness: Object containing the following: + files_openness: Object containing the following: @@ -20207,13 +20256,13 @@ - open: Integer number of files using open formats. + open: Integer number of files using open formats. - closed: Integer number of files using closed/proprietary formats. + closed: Integer number of files using closed/proprietary formats. - other: Integer number of files not categorised in either of the above. + other: Integer number of files not categorised in either of the above. @@ -20222,13 +20271,13 @@ - + - files_encoding: Object containing the following: + files_encoding: Object containing the following: @@ -20243,13 +20292,13 @@ - binary: Integer number of files using binary formats. + binary: Integer number of files using binary formats. - text: Integer number of files using text-based formats. + text: Integer number of files using text-based formats. - other: Integer number of files not categorised in either of the above. + other: Integer number of files not categorised in either of the above. @@ -20258,11 +20307,11 @@ - + - files_info: Object containing the following: + files_info: Object containing the following: @@ -20273,83 +20322,83 @@ - total_files: Integer of total number of files in the repository. + total_files: Integer of total number of files in the repository. - ecad_files: Integer number of electronic CAD files. + ecad_files: Integer number of electronic CAD files. - mcad_files: Integer number of mechanical CAD files. + mcad_files: Integer number of mechanical CAD files. - image_files: Integer number of image files. + image_files: Integer number of image files. - data_files: Integer number of data files. + data_files: Integer number of data files. - document_files: Integer number of documentation files. + document_files: Integer number of documentation files. - other_files: Integer number of other types of files. + other_files: Integer number of other types of files. - ecad_proportion: Floating point proportion of electronic CAD files. + ecad_proportion: Floating point proportion of electronic CAD files. - mcad_proportion: Floating point proportion of mechanical CAD files. + mcad_proportion: Floating point proportion of mechanical CAD files. - image_proportion: Floating point proportion of image files. + image_proportion: Floating point proportion of image files. - data_proportion: Floating point proportion of data files. + data_proportion: Floating point proportion of data files. - document_proportion: Floating point proportion of documentation files. + document_proportion: Floating point proportion of documentation files. - other_proportion: Floating point proportion of other types of files. + other_proportion: Floating point proportion of other types of files. - + - license: Object containing license information: + license: Object containing license information: - + - key: String of license identifier. Currently the same as spdx_id. + key: String of license identifier. Currently the same as spdx_id. - name: Full name of license. + name: Full name of license. - spdx_id: String of the SPDX license identifier. + spdx_id: String of the SPDX license identifier. - url: URL to license text. + url: URL to license text. - node_id: For some licenses, this will be an identifier in GitHub’s license list. + node_id: For some licenses, this will be an identifier in GitHub’s license list. - html_url: URL to license information. + html_url: URL to license information. - permissions: Array of strings containing the permissions given by the license, which could include: + permissions: Array of strings containing the permissions given by the license, which could include: @@ -20364,19 +20413,19 @@ - commercial-use: This work and derivatives may be used for commercial purposes. + commercial-use: This work and derivatives may be used for commercial purposes. - modifications: This work may be modified. + modifications: This work may be modified. - distribution: This work may be distributed. + distribution: This work may be distributed. - private-use: This work may be used and modified in private. + private-use: This work may be used and modified in private. - patent-use: This license provides an express grant of patent rights from contributors. + patent-use: This license provides an express grant of patent rights from contributors. @@ -20385,13 +20434,13 @@ - + - conditions: Array of strings expressing the conditions under which the work could be used, which could include a combination of: + conditions: Array of strings expressing the conditions under which the work could be used, which could include a combination of: @@ -20406,28 +20455,28 @@ - include-copyright: A copy of the license and copyright notice must be included with the work. + include-copyright: A copy of the license and copyright notice must be included with the work. - include-copyright--source: A copy of the license and copyright notice must be included with the work in when distributed in source form. + include-copyright--source: A copy of the license and copyright notice must be included with the work in when distributed in source form. - document-changes: Changes made to the source/documentation must be documented. + document-changes: Changes made to the source/documentation must be documented. - disclose-source: Source code/documentation must be made available when the work is distributed. + disclose-source: Source code/documentation must be made available when the work is distributed. - network-use-disclose: Users who interact with software via network are given the right to receive a copy of the source code. + network-use-disclose: Users who interact with software via network are given the right to receive a copy of the source code. - same-license: Modifications must be released under the same license when distributing the work. In some cases a similar or related license may be used. + same-license: Modifications must be released under the same license when distributing the work. In some cases a similar or related license may be used. - same-license--file: Modifications of existing files must be released under the same license when distributing the work. In some cases a similar or related license may be used. + same-license--file: Modifications of existing files must be released under the same license when distributing the work. In some cases a similar or related license may be used. - same-license--library: Modifications must be released under the same license when distributing software. In some cases a similar or related license may be used, or this condition may not apply to works that use the software as a library. + same-license--library: Modifications must be released under the same license when distributing software. In some cases a similar or related license may be used, or this condition may not apply to works that use the software as a library. @@ -20436,13 +20485,13 @@ - + - limitations: Limitations of the license, which could include a combination of: + limitations: Limitations of the license, which could include a combination of: @@ -20457,16 +20506,16 @@ - trademark-use: This license explicitly states that it does NOT grant trademark rights, even though licenses without such a statement probably do not grant any implicit trademark rights. + trademark-use: This license explicitly states that it does NOT grant trademark rights, even though licenses without such a statement probably do not grant any implicit trademark rights. - liability: This license includes a limitation of liability. + liability: This license includes a limitation of liability. - patent-use: This license explicitly states that it does NOT grant any rights in the patents of contributors. + patent-use: This license explicitly states that it does NOT grant any rights in the patents of contributors. - warranty: The license explicitly states that it does NOT provide any warranty. + warranty: The license explicitly states that it does NOT provide any warranty. @@ -20475,14 +20524,14 @@ - + - tags: Aggregated array of strings representing the tags associated with the repository, and tags associated with users who are maintainers/owners of the repository. The implementation of this might change as WIF implements their skill-based matchmaking features. Examples: “open-source”, “raspberry-pi”, “space”, “3d-printing”. + tags: Aggregated array of strings representing the tags associated with the repository, and tags associated with users who are maintainers/owners of the repository. The implementation of this might change as WIF implements their skill-based matchmaking features. Examples: “open-source”, “raspberry-pi”, “space”, “3d-printing”. - commits_level: Array of objects representing commits (contributions in WIF), where each one would contain: + commits_level: Array of objects representing commits (contributions in WIF), where each one would contain: @@ -20493,21 +20542,21 @@ - hash: A string, where for Git-based repositories, the unique hash identifier for the commit. For WIF, this is the id field of the contribution. + hash: A string, where for Git-based repositories, the unique hash identifier for the commit. For WIF, this is the id field of the contribution. - committed: String containing the timestamp for the commmit in ISO 8601 format, e.g. 2018-04-25T20:35:59.614973+00:00. + committed: String containing the timestamp for the commmit in ISO 8601 format, e.g. 2018-04-25T20:35:59.614973+00:00. - + - issues_level: Array of objects representing issues, where each one would contain: + issues_level: Array of objects representing issues, where each one would contain: @@ -20518,16 +20567,16 @@ - id: String containing the URL to the issue. + id: String containing the URL to the issue. - published: String containing the creation date of the issue in ISO 8601 format, e.g. 2018-04-25T20:35:59.614973+00:00. + published: String containing the creation date of the issue in ISO 8601 format, e.g. 2018-04-25T20:35:59.614973+00:00. - isResolved: Boolean (true or false) of whether the issue has been marked as closed or resolved. + isResolved: Boolean (true or false) of whether the issue has been marked as closed or resolved. - resolved: String containing ISO 8601 formatted timestamp representing the last time there was activity in the issue (such as comments), or if the issue isResolved, the time it happened. + resolved: String containing ISO 8601 formatted timestamp representing the last time there was activity in the issue (such as comments), or if the issue isResolved, the time it happened. @@ -20537,84 +20586,84 @@ Notes: - For files_editability above, file types are identified by file extensions. The categories and mapping are documented in oshminer/filetypes.py, and can be traced the osh-file-types list by Open Source Ecology Germany. + For files_editability above, file types are identified by file extensions. The categories and mapping are documented in oshminer/filetypes.py, and can be traced the osh-file-types list by Open Source Ecology Germany. - For files_info above, file types are identified by file extensions. The categories and mapping are located in oshminer/filetypes.py. + For files_info above, file types are identified by file extensions. The categories and mapping are located in oshminer/filetypes.py. - The license information and formatting is largely based on that from the GitHub-managed choosealicense.com repository, with the exception of some open source hardware licenses which were manually added. + The license information and formatting is largely based on that from the GitHub-managed choosealicense.com repository, with the exception of some open source hardware licenses which were manually added. - Custom Wikifactory URLs - By default, this tool will identify whether a provided repository URL in the JSON request body as a WIF project if it is under the domain wikifactory.com + Custom Wikifactory URLs + By default, this tool will identify whether a provided repository URL in the JSON request body as a WIF project if it is under the domain wikifactory.com Frontend sample implementation - Like the installation instructions for the backend, this section also assumes knowledge of Python, Git, and using a GNU/Linux-based server including installing software from package managers and running a terminal session. - In addition, familiarity with JupyterLab and the Plotly plotting library are helpful when making modifications to the code. - This project requires Python version 3.10 or later on your server and running it in a Python virtual environment is optional but recommended. Detailed external library dependencies are listed in the standard-conformant requirements.txt file and also here: + Like the installation instructions for the backend, this section also assumes knowledge of Python, Git, and using a GNU/Linux-based server including installing software from package managers and running a terminal session. + In addition, familiarity with JupyterLab and the Plotly plotting library are helpful when making modifications to the code. + This project requires Python version 3.10 or later on your server and running it in a Python virtual environment is optional but recommended. Detailed external library dependencies are listed in the standard-conformant requirements.txt file and also here: - jupyterlab>=3.4.5 + jupyterlab>=3.4.5 - mljar-mercury>=1.1.5 + mljar-mercury>=1.1.5 - pandas>=1.4.3 + pandas>=1.4.3 - plotly>=5.10 + plotly>=5.10 In addition to Python and the dependencies listed above, the following programs must be installed and accessible from the command line: - git (version 2.7.4 or later) + git (version 2.7.4 or later) - pip (version 19.3.1 or later) + pip (version 19.3.1 or later) - Running locally from source - The code can be run from source and has been tested on updated versions of GNU/Linux server operating systems including Red Hat Enterprise Linux 8.7. While effort has been made to keep the Python scripts and JupyterLab notebook platform-agnostic, they have not been tested under other operating systems such as BSD-derivatives, Apple macOS or Microsoft Windows as they - especially the latter two - are rarely used for hosting code such as this. - On your server, with the tools git and pip installed, run the following commands in a terminal session to retrieve the latest version of this repository and prepare it for development and running locally (usually for testing): - git clone https://github.com/OPEN-NEXT/wp2.2_frontend_dev.git - pip install --user -r requirements.txt - The git command will download the files in this repository onto your server into a directory named wp2.2_frontend_dev, and pip will install the Python dependencies listed in requirements.txt. - In a terminal window at the root directory of this repository, start the server with the mercury command like this: - mercury run ./repos.ipynb + Running locally from source + The code can be run from source and has been tested on updated versions of GNU/Linux server operating systems including Red Hat Enterprise Linux 8.7. While effort has been made to keep the Python scripts and JupyterLab notebook platform-agnostic, they have not been tested under other operating systems such as BSD-derivatives, Apple macOS or Microsoft Windows as they - especially the latter two - are rarely used for hosting code such as this. + On your server, with the tools git and pip installed, run the following commands in a terminal session to retrieve the latest version of this repository and prepare it for development and running locally (usually for testing): + git clone https://github.com/OPEN-NEXT/wp2.2_frontend_dev.git + pip install --user -r requirements.txt + The git command will download the files in this repository onto your server into a directory named wp2.2_frontend_dev, and pip will install the Python dependencies listed in requirements.txt. + In a terminal window at the root directory of this repository, start the server with the mercury command like this: + mercury run ./repos.ipynb There will be some output in the terminal. If there are no obvious error messages, this means the demo frontend is up an running, and should be accessible on your local machine on port 8000 at 127.0.0.1 (i.e. 127.0.0.1:8000). - Note: By default, the JupyterLab notebook repos.ipynb will use data contained in contrib/GitHub_repos_data.json and visualise them. This JSON file contains data from various open source hardware repositories hosted on GitHub. It is the same information that the dashboard backend API will provide. - A demo of this is available at this URL: - http://wp22-frontend.us.to - Deploy to web - The code in this repository can be directly deployed to a cloud web app hosting provider such as Fly.io or Heroku. Here is an example of deploying to Heroku (assuming you already have an Heroku account): + Note: By default, the JupyterLab notebook repos.ipynb will use data contained in contrib/GitHub_repos_data.json and visualise them. This JSON file contains data from various open source hardware repositories hosted on GitHub. It is the same information that the dashboard backend API will provide. + A demo of this is available at this URL: + http://wp22-frontend.us.to + Deploy to web + The code in this repository can be directly deployed to a cloud web app hosting provider such as Fly.io or Heroku. Here is an example of deploying to Heroku (assuming you already have an Heroku account): - Make sure your terminal prompt is in the root directory of this repository. With the Heroku commandline interface installed, login with this command: + Make sure your terminal prompt is in the root directory of this repository. With the Heroku commandline interface installed, login with this command: - heroku container:login + heroku container:login - Create a new Heroku app where “your app name” can be a name of your choosing: + Create a new Heroku app where “your app name” can be a name of your choosing: - heroku create [your app name] + heroku create [your app name] - It may take a couple minutes for the app to come online. You can check your Heroku account dashboard for a status update. Once it is online, you can open the app in your web browser: + It may take a couple minutes for the app to come online. You can check your Heroku account dashboard for a status update. Once it is online, you can open the app in your web browser: - heroku open - Usage - Frontends showing project status metrics from the dashboard backend API can be implemented independently. Such a frontend can show aggregate information about open source hardware projects hosted on GitHub or WIF. - A major component of this deliverable is that WIF has implemented various frontend dashboard features. Some of these features are in production an viewable on various WIF projects. According to WIF, the features will be gradually rolled out to all WIF projects beginning September 2022. - In addition to that, this repository implements a demo frontend that shows information about open source hardware repositories hosted on GitHub. After deploying this demo per the installation steps above, open it in your web browser. You can also visit a demo instance at: http://wp22-frontend.us.to + heroku open + Sample frontend usage + Frontends showing project status metrics from the dashboard backend API can be implemented independently. Such a frontend can show aggregate information about open source hardware projects hosted on GitHub or WIF. + A major component of this deliverable is that WIF has implemented various frontend dashboard features. Some of these features are in production an viewable on various WIF projects. According to WIF, the features will be gradually rolled out to all WIF projects beginning September 2022. + In addition to that, this repository implements a demo frontend that shows information about open source hardware repositories hosted on GitHub. After deploying this demo per the installation steps above, open it in your web browser. You can also visit a demo instance at: http://wp22-frontend.us.to The following are basic steps for interacting with the demo: - When first loaded, there will be an initial page like this (Figure 6): + When first loaded, there will be an initial page like this (Figure 6): @@ -21393,10 +21442,10 @@ iigAooooAKKKKACiiigAooooAKKKKACiiigD/9k= - Figure 6. Initial view of demo frontend. + Figure 6. Initial view of demo frontend. - Under the “Choose a repository” menu, you can choose from a pre-populated list of GitHub repositories (chosen to represent various states of OSH documentation, some of which studied for D2.6 “Second release of models and standards for design reuse”), such as nasa-jpl/open-source-rover (Figure 7): + Under the “Choose a repository” menu, you can choose from a pre-populated list of GitHub repositories (chosen to represent various states of OSH documentation, some of which studied for D2.6 “Second release of models and standards for design reuse”), such as nasa-jpl/open-source-rover (Figure 7): @@ -22184,10 +22233,10 @@ VlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVgIAgS+0/9k= - Figure 7. Choosing a GitHub repository to show visualisations for. + Figure 7. Choosing a GitHub repository to show visualisations for. - Click on the green “Run” button and wait several seconds for the code to run. You should then see a series of visualisations on the right (Figure 8), e.g.: + Click on the green “Run” button and wait several seconds for the code to run. You should then see a series of visualisations on the right (Figure 8), e.g.: @@ -23009,16 +23058,16 @@ bwODaRm4DzDZ7J53Uvmu+3U45PG6k5IDdZZYN0ZOb87f43X/2Q== - Figure 8. Partial screenshot of some visualisations on the dashboard frontend. + Figure 8. Partial screenshot of some visualisations on the dashboard frontend. - The total collection of visualisations in the front end demonstrator of the dashboard consists of “Commits history”, “Issues opened/closed”, a list of “Tags” for the repository, and pie chart breakdowns of “File type” and “File editability”, followed by “License information”. Some of these visualisations are interactive. + The total collection of visualisations in the front end demonstrator of the dashboard consists of “Commits history”, “Issues opened/closed”, a list of “Tags” for the repository, and pie chart breakdowns of “File type” and “File editability”, followed by “License information”. Some of these visualisations are interactive. - For graphs such as commit and issue histories, you can use your mouse to click and drag a box to zoom in to (Figure 9): + For graphs such as commit and issue histories, you can use your mouse to click and drag a box to zoom in to (Figure 9): - + /9j/4AAQSkZJRgABAQEASABIAAD//gATQ3JlYXRlZCB3aXRoIEdJTVD/4gKwSUNDX1BST0ZJ TEUAAQEAAAKgbGNtcwQwAABtbnRyUkdCIFhZWiAH5gAIAA4ADwAdAAFhY3NwQVBQTAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAA @@ -23508,13 +23557,13 @@ LuhzogDWESLYtLBfhTZsyBhEpMDOa7RpMnY3KUyJnUYScMklFuqv/Z//2Q== - Figure 9. Drag box to zoom into plots. + Figure 9. Drag box to zoom into plots. - Or, when you hover your mouse cursor over a slice in a pie chart, it will display a tool tip. In this screenshot, it is showing that 11.2% of the files in the nasa-jpl/open-source-rover repository are “ECAD” (electronics CAD) files (Figure 10): + Or, when you hover your mouse cursor over a slice in a pie chart, it will display a tool tip. In this screenshot, it is showing that 11.2% of the files in the nasa-jpl/open-source-rover repository are “ECAD” (electronics CAD) files (Figure 10): - + /9j/4AAQSkZJRgABAQEASABIAAD//gATQ3JlYXRlZCB3aXRoIEdJTVD/4gKwSUNDX1BST0ZJ TEUAAQEAAAKgbGNtcwQwAABtbnRyUkdCIFhZWiAH5gAIAA4ADwAdAAFhY3NwQVBQTAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAA @@ -23758,10 +23807,10 @@ LgBiO41pQm+QYfe80Ua0DvD+imtQAD/dz/4j/9k= - Figure 10. Tool tips for slices in pie charts. + Figure 10. Tool tips for slices in pie charts. - For each visualisation, you can hover your mouse cursor over the top right to reveal more controls, such as a “camera” button for downloading a PNG image of the current view (Figure 11): + For each visualisation, you can hover your mouse cursor over the top right to reveal more controls, such as a “camera” button for downloading a PNG image of the current view (Figure 11): @@ -23862,67 +23911,68 @@ /9k= - Figure 11. Additional tools for each visualisation. + Figure 11. Additional tools for each visualisation. - An additional feature is the blue “Download” button. Clicking this will allow you to download the visualisations as a PDF or HTML file for local viewing. + An additional feature is the blue “Download” button. Clicking this will allow you to download the visualisations as a PDF or HTML file for local viewing. - Summary - Task 2.2 (T2.2) in the OPEN_NEXT project has – through the development of this deliverable – put the project status dashboard features we developed into production on the WIF platform. The development process involved: + Summary + Task 2.2 (T2.2) in the OPEN_NEXT project has – through the development of this deliverable – put the project status dashboard features we developed into production on the WIF platform. The development process involved: - an initial proof-of-concept delivered in D2.3 during month 18; + an initial proof-of-concept delivered in D2.3 during month 18; - a requirements capture process to map brainstormed dashboard features to WIF stakeholders and their needs; + a requirements capture process to map brainstormed dashboard features to WIF stakeholders and their needs; - a survey of OSH practitioners to prioritise the most useful dashboard features; + a survey of OSH practitioners to prioritise 10 the most useful dashboard features; - implementing server-side code for data mining from GitHub and WIF repositories for the dashboard backend; + implementing server-side code for data mining from GitHub and WIF repositories for the dashboard backend for 6 of those features; - creating a new dashboard demo frontend for GitHub projects; + creating a new dashboard demo frontend for GitHub projects of all of those features; - and dashboard frontend elements deployed in the real-world scenario of WIF projects. + and dashboard frontend elements deployed in the real-world scenario of WIF projects of 2 of those features. - The backend and frontend code of the D2.5 project status dashboard are flexible enough to be hosted separately. Projects and hosting platforms can choose whether to implement the frontend on their own. This flexibility allows the dashboard components to be platform-agnostic, instead of being exclusively tied to WIF. This, along with the fact that all components of this deliverable have been published under open source licenses following industry best practices, allows and facilitates broader adoption to use cases and platforms beyond OPEN_NEXT. - The business value from T2.2 includes upgrades to the WIF platform based on the research conducted and software developed through this deliverable. The survey conducted will also aid WIF to focus their future development efforts of their platform’s frontend to integrate dashboard features prioritised through the survey results. This allows continued impact and value-creation beyond the life of the OPEN_NEXT project, and will further benefit the wider OSH community. - Acknowledgements - The primary author would like to gratefully acknowledge: + The backend and frontend code of the D2.5 project status dashboard are flexible enough to be hosted separately. Projects and hosting platforms can choose whether to implement the frontend on their own and “plug” it into our backend code. This flexibility allows the dashboard components to be platform-agnostic, instead of being exclusively tied to WIF. To deploy the project status dashboard within GitHub, their developers would need to make decisions to roll out these features to their clients. Alternatively, individual project owners could deploy our project status dashboard code on their own servers and would then show on their own websites or Github repository pages. + This, along with the fact that all components of this deliverable have been published under open source licenses following industry best practices, allows and facilitates broader adoption to use cases and platforms beyond OPEN_NEXT. + The business value from T2.2 includes upgrades to the WIF platform based on the research conducted and software developed through this deliverable. The survey conducted will also aid WIF to focus their future development efforts of their platform’s frontend to integrate dashboard features prioritised through the survey results. This allows continued impact and value-creation beyond the life of the OPEN_NEXT project, and will further benefit the wider OSH community. + Acknowledgements + The primary author would like to gratefully acknowledge: - Dr Jérémy Bonvoisin (@jbon) not only for the initial contributions to this work, but also for continued practical and theoretical insight, generosity, and guidance. + Dr Jérémy Bonvoisin (@jbon) not only for the initial contributions to this work, but also for continued practical and theoretical insight, generosity, and guidance. - Dr Elies Dekoninck (@elies30) and Rafaella Antoniou (@rafaellaantoniou) for valuable feedback and support. + Dr Elies Dekoninck (@elies30) and Rafaella Antoniou (@rafaellaantoniou) for valuable feedback and support. - Max Kampik (@mkampik), Diego Vaquero, and Andrés Barreiro from WIF for close collaboration, design insights, and technical support throughout the project. + Max Kampik (@mkampik), Diego Vaquero, and Andrés Barreiro from WIF for close collaboration, design insights, and technical support throughout the project. - Jean-François Boujut (@boujut) and the rest of WP2. + Jean-François Boujut (@boujut) and the rest of WP2. - OPENNEXT internal reviewers Sonika Gogineni (@GoSFhg) and Martin Häuer (@moedn) for constructive criticism on the D2.5 report. + OPENNEXT internal reviewers Sonika Gogineni (@GoSFhg) and Martin Häuer (@moedn) for constructive criticism on the D2.5 report. - OPENNEXT project researchers Robert Mies (@MIE5R0) and Mehera Hassan (@meherrahassan) for useful feedback and extensive administrative support. + OPENNEXT project researchers Robert Mies (@MIE5R0) and Mehera Hassan (@meherrahassan) for useful feedback and extensive administrative support. - The Linux Foundation CHAOSS group for insights on open source community health metrics. + The Linux Foundation CHAOSS group for insights on open source community health metrics. - The following people for their valuable survey feedback (in alphabetical order of last name): Jean-François Boujut (@boujut), Martin Häuer (@moedn), James Jones (CubeSpawn), Max Kampik (@mkampik), Johannes Střelka-Petz. + The following people for their valuable survey feedback (in alphabetical order of last name): Jean-François Boujut (@boujut), Martin Häuer (@moedn), James Jones (CubeSpawn), Max Kampik (@mkampik), Johannes Střelka-Petz. - Annex - This annex contains two tables containing WIF stakeholder information needs (Table 2) and possible dashboard frontend features to fulfil those needs (Table 3). - + Annex + This annex contains two tables containing WIF stakeholder information needs (Table 2) and possible dashboard frontend features to fulfil those needs (Table 3). + Table 2. Dashboard features linked to stakeholder information needs (“+” indicates a clear relationship). @@ -23934,36 +23984,36 @@ - + - + - Information needs + Information needs - + - + - + - + - + - Feature + Feature - Feature number + Feature number Activity level @@ -23986,1758 +24036,1758 @@ - File types + File types 1 - + - + - + - + + + - + - + + + - Contribution types + Contribution types 2 - + - + + + - + + + - + - + - + + + - Issues opened/closed + Issues opened/closed 3 - + + + - + + + - + - + - + + + - + - Issues opened/closed over time + Issues opened/closed over time 4 - + + + - + + + - + - + - + + + - + + + - Issue triage time + Issue triage time 5 - + + + - + + + - + - + - + + + - + + + - Issue time to close + Issue time to close 6 - + + + - + + + - + - + - + + + - + + + - Issue age distribution + Issue age distribution 7 - + + + - + + + - + - + - + + + - + - Issue activity level + Issue activity level 8 - + + + - + + + - + - + - + + + - + + + - Users active/inactive + Users active/inactive 9 - + + + - + + + - + + + - + - + + + - + + + - User activity over time (G) + User activity over time (G) 10 - + + + - + + + - + + + - + - + + + - + - Commits + Commits 11 - + + + - + - + - + - + - + - Commits over time + Commits over time 12 - + + + - + - + - + - + - + - Commits rate of change + Commits rate of change 13 - + + + - + - + - + - + - + - Network graph of users + Network graph of users 14 - + + + - + + + - + + + - + - + - + + + - Network graph playback + Network graph playback 15 - + - + + + - + + + - + - + - + - Show projects with similar graphs + Show projects with similar graphs 16 - + - + + + - + - + - + - + - Centrality and modularity + Centrality and modularity 17 - + + + - + + + - + - + - + - + + + - Bus factor + Bus factor 18 - + + + - + + + - + - + - + - + + + - Project tags + Project tags 19 - + - + + + - + - + - + - + + + - User tags + User tags 20 - + - + - + + + - + - + - + - Project skill tags/profile + Project skill tags/profile 21 - + - + + + - + - + + + - + - + + + - User skill tags/profile + User skill tags/profile 22 - + - + - + + + - + + + - + - + + + - Manufacturing metadata + Manufacturing metadata 23 - + - + - + - + + + - + - + + + - Standards compliance metadata + Standards compliance metadata 24 - + - + - + - + + + - + - + - CONTRIBUTING file + CONTRIBUTING file 25 - + - + + + - + - + + + - + - + + + - GOVERNANCE file + GOVERNANCE file 26 - + - + + + - + - + + + - + - + + + - LICENSE file and meanings + LICENSE file and meanings 27 - + - + - + - + + + - + - + - README file + README file 28 - + - + + + - + - + + + - + - + + + - CODE OF CONDUCT file + CODE OF CONDUCT file 29 - + - + + + - + - + + + - + - + + + - Communications channels + Communications channels 30 - + - + + + - + - + + + - + + + - + + + - Downloads + Downloads 31 - + + + - + - + - + - + + + - + - Downloads rate + Downloads rate 32 - + + + - + - + - + - + + + - + - Replicability + Replicability 33 - + - + - + - + + + - + - + + + - Replication rate + Replication rate 34 - + - + - + - + + + - + - + - Forks + Forks 35 - + - + - + - + - + + + - + - Followers + Followers 36 - + - + + + - + + + - + - + + + - + - Citations + Citations 37 - + - + + + - + - + + + - + + + - + - Primary maintainers + Primary maintainers 38 - + + + - + + + - + + + - + + + - + - + + + - Project age + Project age 39 - + - + - + - + - + + + - + - Releases + Releases 40 - + + + - + - + - + + + - + + + - + + + - Motivation indicators + Motivation indicators 41 - + + + - + + + - + + + - + + + - + - + + + - Files editability + Files editability 42 - + - + - + - + + + - + - + + + - Use of open vs proprietary files + Use of open vs proprietary files 43 - + - + - + - + + + - + - + + + - Documentation update rate + Documentation update rate 44 - + - + - + - + + + - + - + + + - Different view for different audience + Different view for different audience 45 - + - + - + - + - + - + - Badges and achievements + Badges and achievements 46 - + - + - + - + - + - + - Embeddable card view + Embeddable card view 47 - + - + - + - + - + - + - On-demand data-mining + On-demand data-mining 48 - + - + - + - + - + - + - Derived statements + Derived statements 49 - + - + - + - + - + - + - Tooltips + Tooltips 50 - + - + - + - + - + - + - Qualitative statements + Qualitative statements 51 - + - + - + - + - + - + - Table 2. Dashboard features linked to stakeholder information needs (“+” indicates a clear relationship). - + + Table 3. Definitions of putative dashboard features. Items in bold were prioritised during the requirements capture exercise. - Feature + Feature - Description + Description - File types + File types - Classify files into "mechanical/electrical/software/documentation" and by proportion. + Classify files into "mechanical/electrical/software/documentation" and by proportion. - Contribution types + Contribution types - Similar to file types groupings, but relative to content of commit / contribution. + Similar to file types groupings, but relative to content of commit / contribution. - Issues opened/closed + Issues opened/closed - Number of currently open and closed issues. + Number of currently open and closed issues. - Issues opened/closed over time + Issues opened/closed over time - A time-series graph. + A time-series graph. - Issue triage time + Issue triage time - How long does it take on average for someone to respond to an open issue. + How long does it take on average for someone to respond to an open issue. - Issue time to close + Issue time to close - Average time for an issue to be closed. + Average time for an issue to be closed. - Issue age distribution + Issue age distribution - To answer questions like: “Are there many old issues that are still open?” + To answer questions like: “Are there many old issues that are still open?” - Issue activity level + Issue activity level - Graph of issue activities (open/close/comments) over time. + Graph of issue activities (open/close/comments) over time. - Users active/inactive + Users active/inactive - Need to define what counts as “active”, which is probably activity over a period of time. And proportions. + Need to define what counts as “active”, which is probably activity over a period of time. And proportions. - User activity over time + User activity over time - Such as a graph of user activity over time. Possibly grouped by issues and commits, and maybe even commit type like CAD, documentation, etc. + Such as a graph of user activity over time. Possibly grouped by issues and commits, and maybe even commit type like CAD, documentation, etc. - Commits + Commits - Number of commits in this repository. + Number of commits in this repository. - Commits over time + Commits over time - Graph of commits over time. + Graph of commits over time. - Commits rate of change + Commits rate of change - To show things like “commits have been slowing down over the past 3 months”. + To show things like “commits have been slowing down over the past 3 months”. - Network graph of users + Network graph of users - An interactive visualisation of users as nodes, connected by if they have worked on the same issues or files. + An interactive visualisation of users as nodes, connected by if they have worked on the same issues or files. - Network graph playback + Network graph playback - Playback of the graph to see how it changed over time. + Playback of the graph to see how it changed over time. - Show projects with similar graphs + Show projects with similar graphs - Suggest projects with similar graph structure. + Suggest projects with similar graph structure. - Centrality and modularity + Centrality and modularity - High centrality means project is maintained by one/few people. Modularity measures if the community has clear sub-groups working on different things. + High centrality means project is maintained by one/few people. Modularity measures if the community has clear sub-groups working on different things. - Bus factor + Bus factor - How much the project depends on one/few user(s). + How much the project depends on one/few user(s). - Project generic tags + Project generic tags - Show arbitrary tags the project decides to attach to itself. + Show arbitrary tags the project decides to attach to itself. - User generic tags + User generic tags - Show arbitrary tags a user attaches to themselves. + Show arbitrary tags a user attaches to themselves. - Project skill tags/profile + Project skill tags/profile - Show skill-related tags for a project, probably from the ontology. + Show skill-related tags for a project, probably from the ontology. - User skill tags/profile + User skill tags/profile - Show skill-related tags for a user, probably from the ontology. + Show skill-related tags for a user, probably from the ontology. - Manufacturing metadata + Manufacturing metadata - Display what’s needed for manufacture like “Need 3D printing, PCB fabrication”. + Display what’s needed for manufacture like “Need 3D printing, PCB fabrication”. - Standards compliance metadata + Standards compliance metadata - REUSE, Standard README, DIN-SPEC 3105-1, OKH, OSHWA, or technology readiness levels like OTRL/ODRL. + REUSE, Standard README, DIN-SPEC 3105-1, OKH, OSHWA, or technology readiness levels like OTRL/ODRL. - CONTRIBUTING file + CONTRIBUTING file - Document describing how to contribute to this project. + Document describing how to contribute to this project. - GOVERNANCE file + GOVERNANCE file - Document describing how the project community is governed. + Document describing how the project community is governed. - LICENSE file and meanings + LICENSE file and meanings - Not just which license, but also what type (i.e. CC-licenses, software licenses, or hardware licenses), what it means for the hardware and if it meets certain standards. Info on if it’s a reciprocal or non-reciprocal license. + Not just which license, but also what type (i.e. CC-licenses, software licenses, or hardware licenses), what it means for the hardware and if it meets certain standards. Info on if it’s a reciprocal or non-reciprocal license. - README file + README file - This should be in every repository! + This should be in every repository! - CODE OF CONDUCT file + CODE OF CONDUCT file - Describes code of conduct for the community and how it is enforced. + Describes code of conduct for the community and how it is enforced. - Communications channels + Communications channels - How to get in touch with the community like email(s), phone number(s), websites, forums, chat channels… + How to get in touch with the community like email(s), phone number(s), websites, forums, chat channels… - Downloads + Downloads - Number of downloads (of the repository, releases, and so on). + Number of downloads (of the repository, releases, and so on). - Downloads rate + Downloads rate - How often are the downloads and if this rate changes. + How often are the downloads and if this rate changes. - Replicability + Replicability - Need to better define measures of “replicability”, maybe derive this from how complete the documentation is and if there’s manufacturing metadata? + Need to better define measures of “replicability”, maybe derive this from how complete the documentation is and if there’s manufacturing metadata? - Replication rate + Replication rate - How often is this hardware built by others? + How often is this hardware built by others? - Forks + Forks - Number of forks. + Number of forks. - Followers + Followers - Number of followers (or stars on GitHub). + Number of followers (or stars on GitHub). - Citations + Citations - Number of citations of this project. Need to think about how to implement this. + Number of citations of this project. Need to think about how to implement this. - Primary maintainers + Primary maintainers - List of who are the primary developers/maintainers behind this project? + List of who are the primary developers/maintainers behind this project? - Project age + Project age - How old is this project and when was it created? + How old is this project and when was it created? - Releases + Releases - Does this project have releases and how many releases are there? + Does this project have releases and how many releases are there? - Motivations indicator + Motivations indicator - Show if a project is looking for x (from a list of indicators), where x could be “contributors”, “manufacturing partners”, and many other things. Done in a way that reflects the motivations of the project and possibly their business model. + Show if a project is looking for x (from a list of indicators), where x could be “contributors”, “manufacturing partners”, and many other things. Done in a way that reflects the motivations of the project and possibly their business model. - Files editability + Files editability - Are editable are the files in this repository? E.g. “PDF vs editable CAD files”. + Are editable are the files in this repository? E.g. “PDF vs editable CAD files”. - Use of open vs proprietary files + Use of open vs proprietary files - Does this project use open standard file formats vs proprietary ones? + Does this project use open standard file formats vs proprietary ones? - Documentation update rate + Documentation update rate - How often is the documentation maintained/updated? + How often is the documentation maintained/updated? - Different views for different stakeholders + Different views for different stakeholders - For example, there could be a project owner view that shows a different set of metrics than a visitor view; or a view meant to be embedded on a WIF page. + For example, there could be a project owner view that shows a different set of metrics than a visitor view; or a view meant to be embedded on a WIF page. - Badges and achievements + Badges and achievements - Derived from other measures in this list, probably to help with gamification. Need feedback/thoughts on this. + Derived from other measures in this list, probably to help with gamification. Need feedback/thoughts on this. - Embeddable card view + Embeddable card view - A mini version of the dashboard with key data that could be embedded elsewhere like this: https://github.com/carbon-app/carbon#license + A mini version of the dashboard with key data that could be embedded elsewhere like this: https://github.com/carbon-app/carbon#license - On-demand data-mining + On-demand data-mining - Only mine data from the project repository when a user asks for it. + Only mine data from the project repository when a user asks for it. - Derived statements + Derived statements - Full descriptive sentences derived from other metrics. See below for examples. + Full descriptive sentences derived from other metrics. See below for examples. - Tool tips + Tool tips - Pop up tools tips that explain each feature in this list. Show quantitative basis for statements, and important for qualifying metrics like “Low number of recent commits doesn’t always mean project is dead”. + Pop up tools tips that explain each feature in this list. Show quantitative basis for statements, and important for qualifying metrics like “Low number of recent commits doesn’t always mean project is dead”. - Qualitative statements + Qualitative statements - These are full sentences describing some aspect of the project, derived from other quantitative metrics from this list. See below for some potential statements. + These are full sentences describing some aspect of the project, derived from other quantitative metrics from this list. See below for some potential statements. - Table 3. Definitions of putative dashboard features. Items in bold were prioritised during the requirements capture exercise. + \ No newline at end of file