forked from opencultureagency/Open-Documentation-Guide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
text-ODG-front.txt
82 lines (52 loc) · 3.33 KB
/
text-ODG-front.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
Open Source Documentation Guide
#ASKnet
LEGEND
Steps you absolutely have to take!
Optional steps to make it extra special
1. Openness
In order to make sure your project has open source freedom for others to use and adapt, you need to give it an open source license. Choose from one of these Open Source Licenses:
Copyleft Licenses
CC-BY-SA 4.0
CERN OHL
GPLv3
Permissive Licenses
Apache 2.0
CC-BY 4.0
MIT License
Anything that restricts the use and remix of the project (like NC/ND) or has no license, is NOT Open Source.
1.1. README
Create a description file and put the license text inside your repository. Do this before you publish anything about your project!
2. Platform
Choose a platform that fits your needs. Where will you publish or share content? Eg: github, gitlab, nextcloud, website/wiki, wikifab, wikifactory
Things to keep in mind:
File management, storage, accessibility, exchange, version control, contributions, onboarding, community interaction
WHAT IS THE CONCEPT?
Describe & outline your project idea. You want to share your project with the world? Give it a name, give it a reason to be & give it a go!
2.1. FORUM
A place where people can discuss questions and issues with the project.
Onboarding / forum connected to platform choice eg: github has issues management and tracking included. If people have trouble making the thing, how to suggest improvements, track changes, bugs.
2.2. READ ONLY
Generate READ ONLY output files on each platform to visualize the project. Give people access to VIEW and use the project without making modifications or changes. Ability to READ across platforms to view, without having to use proprietary software.
OPTIONAL:
Provide a development branch for people trying new features.
Each Release provides better reference and enables people to fork (multiple sub streams and variations of the project) and improve your outcome, spread the word and gain new resources and users.
3. Source
Share your source files as soon as possible! Original content files, text, sources are essential from the beginning to help understand what you’re doing and with the process of documentation itself.
Anything READ ONLY is NOT a source file! Don’t make people reverse engineer your work to create or adapt something new.
Keep in mind that Git based systems don’t work well with big sized binary files (videos, large photos or PDFs, etc.), you might upload them somewhere else and share the download link.
3.1. MAINTENANCE
Someone is taking care of follow-up: responding to suggestions, making changes, fixing bugs. Even if you are the product owner, take care of documentation when you make improvements.
4. Guidance
Collaboration is key in Open Source projects and need maintenance, moderation and constant activity.
Create guidance around your project as visually as you can. Facilitate and encourage collaboration with instructions to various target groups.
For example:
Contribution guide: how can people contribute
How to guide: how to use the product
Developer guide: technical steps for developers
5. Release
Release the project in early packages. Give it a version number and provide the best access you can. Version control (eg. Git) based platforms can help with this.
Types of release:
Unstable release (development),
Beta version (pre-release),
Stable release (ready package),
New upgrades/features etc.