Open Source Ecology - Germany - Benutzerbeiträge [de]

File Sharing and Workflow (Hardware)

2023-06-08T19:07:48Z

Germán Crespo: /* The OHO Approach */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|-
|<big>'''Ordner D_entgültige_Version Readme</big>

|-
|<big>'''Ordner E_STEP+PDF Readme</big>
|}

===The OHO Approach===
https://en.oho.wiki/wiki/Process_-_Development_and_documentation 
Fragen in Verbindung mit: 
4.3 Technical documentation 
4.4 Peer-reviews 

https://en.oho.wiki/wiki/Processes_involved_in_Project_Development

https://en.oho.wiki/wiki/Technical_documentation

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-06-08T19:06:12Z

Germán Crespo: /* The OHO Approach */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|-
|<big>'''Ordner D_entgültige_Version Readme</big>

|-
|<big>'''Ordner E_STEP+PDF Readme</big>
|}

===The OHO Approach===
https://en.oho.wiki/wiki/Process_-_Development_and_documentation
Fragen in Verbindung mit:

4.3 Technical documentation

4.4 Peer-reviews

https://en.oho.wiki/wiki/Processes_involved_in_Project_Development

https://en.oho.wiki/wiki/Technical_documentation

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-06-08T19:04:14Z

Germán Crespo: /* The OHO Approach */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|-
|<big>'''Ordner D_entgültige_Version Readme</big>

|-
|<big>'''Ordner E_STEP+PDF Readme</big>
|}

===The OHO Approach===
https://en.oho.wiki/wiki/Process_-_Development_and_documentation

https://en.oho.wiki/wiki/Processes_involved_in_Project_Development
https://en.oho.wiki/wiki/Technical_documentation

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T11:45:22Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|-
|<big>'''Ordner D_entgültige_Version Readme</big>

|-
|<big>'''Ordner E_STEP+PDF Readme</big>
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T11:42:57Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T11:41:47Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner C_Nacharbeit_notwendig Readme</big>
In diesen Ordner sollten alle 3D-Modelle und technische Zeichnungen verschoben werden, die im Ordner B_zur_Review hochgeladen wurden und nach der Überprüfung als unvollständig oder Fehler enthaltend betrachtet wurden. 
Zum Beispiel:
*Fehlende Abmessungen in den technischen Zeichnungen
*Falsche Abmessungen (Größe) im 3D-Modell
*Etwas fehlt (Formen) im 3D-Modell

Die Dateien behalten hier dem Namensformat wie im Ordner B und bekommen dazu das Suffix '''modify''' 
ME_Bezeichnung wie im Ordner B_'''modify'''.FCStd/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt

|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-27T10:54:27Z

Germán Crespo:

[[File Sharing and Workflow (Hardware)]]

===Evolution der Blücher===
#[https://youtu.be/GBtD1irbsr8 Ein-Trommel Blücher Prototyp/Labormaschine] 
#[https://youtu.be/A4CAPZ7KAtM Zwei-Trommel Blücher 02 Prototyp] 
#[https://youtu.be/J6jhyJNDN2A Zwei-Trommel Blücher 02 auf Traktor mit Rückfahreinrichtung] 
#[https://youtu.be/EgHOhyGH-ww Hanfernte Zwei-Trommel Blücher 02 auf Neuholland Fahrgestell und Fahrwerk]

File Sharing and Workflow (Hardware)

2023-04-27T08:09:44Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T08:08:58Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|<big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|<big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T08:07:44Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|-
|+ <big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T08:06:48Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.

|+ <big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T08:05:17Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

{| class="wikitable"
|+ <big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
:Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
:Zu diesem Ordner ist der Zugang für Kollaborateuren zu ''sehen, herunter- und hochladen"'' eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T08:01:39Z

Germán Crespo: /* general Wiki + Folder Directory Structure */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

{| class="wikitable"
|+ <big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner ''D_endgültige_Version'' verschoben sind.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:58:42Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken Readme'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big> 
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

{| class="wikitable"
|+ <big>'''Ordner B_zur_Review Readme</big>
|-
|In diesem Ordner sollten alle 3D-Modelle und technische Zeichnungen hochgeladen werden, die von den im Ordner ''A_Quellgrafiken'' abgeleitet sind.
Zum Beispiel:
*3D-Modelle ohne technische Zeichnungen
*3D-Modelle mit technische Zeichnungen
*Alleinstehende technische Zeichnungen

Die Dateien müssen mit dem selben Format als in ''A_Quellgrafiken'' benannt werden. Hier ändert sich aber ihre '''Dateiendung: 
ME_Bezeichnung wie in original (Ordner A).'''FCStd/...

<big>''Weiteres...''</big> 
Diese Dateien werden vor Ort und in einer 3D-Assembly überprüft, bevor sie zum Ordner D_endgültige_Version verschoben sind.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:53:24Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ <big>'''Ordner A_Quellgrafiken'''</big>
|-
|In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden: 
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big>
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:52:05Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

{| class="wikitable"
|+ Caption text
|-
|<big>'''A_Quellgrafiken'''</big>
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden:
ME_'''Bezeichnung'''.jpg/.png/...

<big>''Weiteres...''</big>
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
|}

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:48:34Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

<pre>
A_Quellgrafiken
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden:
ME_Bezeichnung.jpg/.png/...

Weiteres...
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.
</pre>

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:46:00Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user


'''A_Quellgrafiken''' 
In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden:
ME_'''Bezeichnung'''.jpg/.png/...

''Weiteres...''
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.


===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-27T07:44:21Z

Germán Crespo:

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

===general Wiki + Folder Directory Structure===
<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user


==A_Quellgrafiken==

In diesem Ordner sollten alle Bilder und Zeichnungen hingelegt werden, die Information für die CAD-Konstruktion der Teile behalten.
Zum Beispiel:
*Fotos
*Fotos mit Abmessungen
*Skizzen

Für diese Dateien wird folgendes Namensformat benutzt werden:
ME_'''Bezeichnung'''.jpg/.png/...

===Weiteres...===
Zu diesem Ordner is der Zugang für Kollaborateuren zu "sehen und herunterladen" eingeschränkt. Keine Dateiänderung / Dateilöschung ist möglich.


===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

File Sharing and Workflow (Hardware)

2023-04-15T19:28:44Z

Germán Crespo: /* File Sharing and Workflow */

The following are a few short notes related to file sharing and workflow.
While the workflow tools for software development are neatly realized and broadly used thanks to platforms like GitHub,
workflow tools for hardware projects, although in existence ([https://opentoolchain.org/ Open Toolchain Foundation]),
do not seem to be integrated in any platform ─at least not in the open-source environment─ that would allow their
combined use and a seamless bidirectional data flow between project developers/participants.
During the annual meeting of OSEG in 2023, a brief comment was made about the necessity of streammlining
the platform for the CAB reviews as to make it more serious and userfriendly. I believe this could be a good
opportunity to also consider the topic of this wiki page.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T19:14:34Z

Germán Crespo: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „File Sharing and Workflow (Hardware)“

[[File Sharing and Workflow (Hardware)]]

File Sharing and Workflow (Hardware)

2023-04-15T19:13:39Z

Germán Crespo: Die Seite wurde neu angelegt: „==File Sharing and Workflow== I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. What motivates me…“

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with.
What motivates me to do this is the impression that, while the workflow tools
for software development are neatly realized and broadly used thanks to platforms like GitHub,
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]),
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is
not quite there yet, or at least not in the open-source environment.

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:29:58Z

Germán Crespo:

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:28:54Z

Germán Crespo: /* wiki + Dropbox */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing Workflow Description] 
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:18:40Z

Germán Crespo: /* wiki + Dropbox */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
[https://drive.google.com/file/d/1BQj12XaIn2qolEnu3BOROZAffzfLsQdL/view?usp=sharing] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:14:39Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:13:58Z

Germán Crespo:

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:10:10Z

Germán Crespo: /* wiki + Dropbox */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders] 
Open with: [https://app.diagrams.net/?src=about Diagrams.net]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-15T18:05:02Z

Germán Crespo:

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 
https://cloud.opensourceecology.de/apps/forms/xiEwEFzwkXdHBqXz 
https://cloud.opensourceecology.de/login 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|
</gallery>
[https://drive.google.com/file/d/1Cay-fRREcdA338_k9V3uRdXJ4bejwxBy/view?usp=sharing Workflow Folders]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T08:32:09Z

Germán Crespo:

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
Datei:Workflow basic 00.drawio.png|gerahmt|links
</gallery>

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Datei:Workflow basic 00.drawio.png

2023-04-06T08:30:45Z

Germán Crespo:

Possible workflow structure (hardware)

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T07:26:58Z

Germán Crespo:

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

===The OHO Approach===

==Useful Links==

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T07:15:07Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: ''Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T07:14:07Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 
: Advantageous tools provided by Nextcloud: Files can be commented and discussions can take place in an associated chat.

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T07:04:19Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T07:01:49Z

Germán Crespo:

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

[https://wiki.opensourceecology.de/Git Git]

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

: Example [https://use04.thegood.cloud/s/TMXkxFTSLZSpMno The Good Cloud]
: Pass. +P{Xer4Jzx

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:51:01Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:50:46Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:49:31Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:49:11Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:48:29Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

 Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich? 

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:44:07Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, comment, discuss etc. These permissions are independent from the user having his or her own account in the system. A link suffices to get access.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:41:09Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, etc. These permissions are independent from the user having his or her own account in the system.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:40:42Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in a local server for internal use like in a company. There, permissions can be given on at least two levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system.
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only downloads and viewing are enabled and there are further restrictions added, namely a mandatory expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:39:36Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the functionality, associated software, and file accessibility depend on how the platform is configured by the party offering the service and the permissions given to the participants.
*:- For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
*:- On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:38:35Z

Germán Crespo: Änderung 24078 von Germán Crespo (Diskussion) rückgängig gemacht.

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the 
functionality, associated software, and file accessibility depend on how the platform is configured 
by the party offering the service and the permissions given to the participants.
: For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
: On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:34:45Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting point that, later on, can be easily organized into a structural part of the project. The wiki facilitates the organization and the search for specifics within a project and within itself thanks to the use of links, embedded views and files, and other types of special formatting. A properly formatted wiki can be a very user-friendly entry point to the project for all users especially in combination with a text-poor file system.

*Nextcloud provides quite a comfortable coworking environment although I have noticed that the 
functionality, associated software, and file accessibility depend on how the platform is configured 
by the party offering the service and the permissions given to the participants.
: For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
: On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:33:15Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting
point that, later on, can be easily organized into a structural part of the project. The wiki
facilitates the organization and the search for specifics within a project and within itself 
thanks to the use of links, embedded views and files, and other types of special formatting. 
A properly formatted wiki can be a very user-friendly entry point to the project for all users 
especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the 
functionality, associated software, and file accessibility depend on how the platform is configured 
by the party offering the service and the permissions given to the participants.
: For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
: On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:32:31Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting
point that, later on, can be easily organized into a structural part of the project. The wiki 
facilitates the organization and the search for specifics within a project and within itself 
thanks to the use of links, embedded views and files, and other types of special formatting. 
A properly formatted wiki can be a very user-friendly entry point to the project for all users 
especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the 
functionality, associated software, and file accessibility depend on how the platform is configured 
by the party offering the service and the permissions given to the participants.
: For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
: On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user

Industrial Hemp Harvesting Machine (fiber)

2023-04-06T06:30:34Z

Germán Crespo: /* wiki + Nextcloud */

==File Sharing and Workflow==
I am going to add a few short notes here about my thoughts related to file sharing and workflow to start with. 
What motivates me to do this is the impression that, while the workflow tools 
for software development are neatly realized and broadly used thanks to platforms like GitHub, 
the workflow tools for hardware projects, although they exist ([https://opentoolchain.org/ Open Toolchain Foundation]), 
a platform that would allow a combined use of these tools and a seamless bidirectional data flow is 
not quite there yet, or at least not in the open-source environment. 

===GitLab===
*als review Werkzeug, wenn alle die Information und die Dateien schon klassifiziert und aufgeräumt sind :)
*als workflow werkzeug für die reverse engineering/development Verfahren :/ 

For example in GitLab I cannot preview images in large tile format, meaning that I have to open the 
file in order to see what is inside. If I wanted to download this file I can not do it from the file 
list but I also have to open the file or choose to download the whole "directory" which translates 
into a high data volume and a higher associated use of energy for its traffic. Another way is the 
cloning and pull-push request approach but for that, I need to install some software on my computer. 

The jargon used in platforms like GitHub makes things even less "user-friendly" since the average Joe 
(Otto Normalverbraucher) or Jane whose contact with the digital world is limited to that of a user for 
practical purposes (saving files or surfing the web) might find this jargon somewhat abstract. In my 
computer a folder is a folder and I think is not a wild guess to assert that most people associate a folder 
with some type of container. In GitLab a folder is called a directory, I personally know that a directory 
is equivalent to a folder because I once used DOS over 20 years ago, otherwise, the first idea that 
comes to mind is a phone directory. 

Although the use and functions of, for example, GitLab are very well documented as it is the case for the 
[https://docs.gitlab.com/ee/topics/git/terminology.html GitLab Terminology]. Here one needs to pose the following question: Who wants to participate 
in the making of a copy of a harvesting machine? or Who wants to participate in the making of a personal 
Loom for woven textiles? or, in short, Who are the target users/collaborators for such a project? And yet, 
despite the answer, the reality is that the whole process should be as easy as possible if I want to maximize 
the participation level. A person whose interest is limited to the creation and formatting of text might find 
the task of writing such text in a wiki just too daunting and might choose to walk away. 

===wiki + Nextcloud===
*A wiki is a very useful container to tip ideas into at the start of a project. A good starting 
point that, later on, can be easily organized into a structural part of the project. The wiki 
facilitates the organization and the search for specifics within a project and within itself 
thanks to the use of links, embedded views and files, and other types of special formatting. 
A properly formatted wiki can be a very user-friendly entry point to the project for all users 
especially in combination with a text-poor file system.
*Nextcloud provides quite a comfortable coworking environment although I have noticed that the 
functionality, associated software, and file accessibility depend on how the platform is configured 
by the party offering the service and the permissions given to the participants.
: For example, it seems that the configuration is most flexible when Nextcloud is being hosted in 
a local server for internal use like in a company. There, permissions can be given on at least two 
levels: view and download only; or view, download, move, delete, etc. These permissions are 
independent from the user having his or her own account in the system. 
: On the other hand, with an online provider like The Good Cloud, without registering an account, only 
downloads and viewing are enabled and there are further restrictions added, namely a mandatory 
expiry date for the shared link to the documents and a mandatory password to access it. 

Wann wird die OSEG Nextcloud verfügbar und was für einstellungen wären für so ein Projekt möglich?

===wiki + Dropbox===

<gallery widths="300" heights="240" perrow="2>
Datei:Workflow basic.drawio.png|gerahmt|links|Possible workflow for the project
</gallery>

===The OHO Approach===

[https://wiki.opensourceecology.de/Git Git]
[https://gitlab.opensourceecology.de/verein/koordination/dokumentation/tools-for-documentation#documentation-creation Werkzeuge für Dokumentation]

one way folder (diode folders) for sharing raw information 
two way folders (with some restrictions e.g. deleting of files) for retrieving processed information 
at least three different access levels would be necessary 
admin/distributor --- contributor/developer --- user