| ... |
... |
@@ -55,9 +55,9 @@ Initially we will work with what we have: |
|
55
|
55
|
|
|
56
|
56
|
The structure is designed to be as "tool agnostic" as possible.
|
|
57
|
57
|
|
|
58
|
|
-We will focus initially on git based content, using gitlab capabilities for it. On the wiki, we will focus on having a good "front page" and improving a little the current content. With this approach, we expect to be ready for when a web comes, reducing the effort associated to keeping the information on sync between git and the GNOME wiki.
|
|
|
58
|
+We will focus initially on git based content, using gitlab capabilities for it. On the wiki, we will focus on having a good "front page" and improving a little the current content. With this approach, we expect to be ready for when a web comes, reducing the effort associated to keeping the information in sync between git and the GNOME wiki.
|
|
59
|
59
|
|
|
60
|
|
-One risk we need to strongly consider is related with the links. There are several ways to mitigate the risk. Whatever measures we apply, they will be a matter of policy so proposals on the mailing list will be required to change them. Breaking links might through to the garbage not just internal references, so pre-defined critical paths, but also external references to our content.
|
|
|
60
|
+One risk we need to strongly consider is related with the links. There are several ways to mitigate the risk. Whatever measures we apply, they will be a matter of policy so proposals on the mailing list will be required to change them. Breaking links might not just affect internal cross-references, which might have an impact on the critical paths that will be described later in thie proposal, but also on references to our content from external sources.
|
|
61
|
61
|
|
|
62
|
62
|
|
|
63
|
63
|
### Timeline
|
| ... |
... |
@@ -106,7 +106,7 @@ Please be aware that these pages will not be designed as the BuildStream front/h |
|
106
|
106
|
The project page and the landing page might be moved to the future web, depending on design, effort and maintenance factors.
|
|
107
|
107
|
|
|
108
|
108
|
|
|
109
|
|
-#### Outcomes as the most influential event
|
|
|
109
|
+#### Releases of outcomes drive the content structure
|
|
110
|
110
|
|
|
111
|
111
|
Assuming the most common journey to become a maintainer (not the only one) being:
|
|
112
|
112
|
|
| ... |
... |
@@ -181,7 +181,7 @@ Together with the Download page, the following gitlab files are essential: |
|
181
|
181
|
* C.4 News/Release notes file - R.3 Feature page and D. BuildStream In Detail content units.
|
|
182
|
182
|
* C.5 Maintainers - Pj.5 Community support and Tools content unit.
|
|
183
|
183
|
|
|
184
|
|
-Changelog has not been consider for now, but it will in the future. It is interesting information for a project focus on systems that needs to be maintained for a long time.
|
|
|
184
|
+Changelog has not been considered for now, but it will in the future. It is interesting information for a project focused on systems that needs to be maintained for a long time.
|
|
185
|
185
|
|
|
186
|
186
|
C.1 BuildStream download page
|
|
187
|
187
|
|
| ... |
... |
@@ -193,13 +193,13 @@ This unit will include, at least, the following content: |
|
193
|
193
|
* Platforms where BuildStream is expected to be installed.
|
|
194
|
194
|
* Deployment mechanisms/technologies.
|
|
195
|
195
|
* Complementary plugins and tools required for the deployment/installation/usage of BuildStream.
|
|
196
|
|
-* Additional content units that any user needs to consider.
|
|
|
196
|
+* Additional content units that any user needs to consider.
|
|
197
|
197
|
* Critical path design to ensure that the journey through BuildStream contents takes place in the pre-established order. This consideration applies in fact to, at least, every unit that is part of the critical path of any considered target audience.
|
|
198
|
198
|
|
|
199
|
199
|
|
|
200
|
200
|
C.2 README files
|
|
201
|
201
|
|
|
202
|
|
-Short, to the point, description of what is BuildStream for and how to consume it, together with links to further information, adding context to each one of them. That additional or complementary information could be (related with):
|
|
|
202
|
+Short, to the point, description of what BuildStream is for and how to consume it, together with links to further information, adding context to each one of them. That additional or complementary information could be (related with):
|
|
203
|
203
|
|
|
204
|
204
|
* Documentation - D. BuildStream in detail unit
|
|
205
|
205
|
* Community support (get help) - D.5 FAQ.
|
| ... |
... |
@@ -221,7 +221,7 @@ Relations: C.3 LICENSE file - Pj.2 Governance+license+sponsors content units. A |
|
221
|
221
|
|
|
222
|
222
|
C.4 NEWS/Release Notes file.
|
|
223
|
223
|
|
|
224
|
|
-News related with each release (digested release notes). Further content can be considered in this unit or separate ones like:
|
|
|
224
|
+News related with each release (digested release notes). Further information can be considered in this content unit or new one like:
|
|
225
|
225
|
|
|
226
|
226
|
* Changelog
|
|
227
|
227
|
* Raw release notes.
|
| ... |
... |
@@ -293,7 +293,7 @@ It is important to link the feature descriptions to code, so the content is wort |
|
293
|
293
|
|
|
294
|
294
|
D.1 Integrate with BuildStream: examples
|
|
295
|
295
|
|
|
296
|
|
-Examples of how to use the tool. The content can be created and maintained by the project itself and or referenced from work done outside the project. AS in other cases, it should be a clear difference between what is expected to be maintained by the project participants and what is "external". This is relevant when requesting/providing support to users and when managing negative feedback on internet.
|
|
|
296
|
+Examples of how to use the tool. The content can be created and maintained by the project itself and/or referenced from work done outside the project. As in other cases, there should be a clear difference between what is expected to be maintained by the project participants and what is "external". This is relevant when requesting/providing support to users and when managing negative feedback on internet.
|
|
297
|
297
|
|
|
298
|
298
|
|
|
299
|
299
|
D.2 BuildStream plug-ins and other complementary features
|
| ... |
... |
@@ -308,7 +308,7 @@ Detailed description of the core features shipped by BuildStream, including thos |
|
308
|
308
|
|
|
309
|
309
|
D.4 BuildStream glossary
|
|
310
|
310
|
|
|
311
|
|
-Each project uses specific terminology that requires explanation. In regulated or safety critical environments or in Open Ocean, this need becomes almost a requirement. The same principle applies to mature markets when using terminology as a differentiation element.
|
|
|
311
|
+Each project uses specific terminology that requires explanation. In regulated or safety critical environments or in Blue Ocean[5], this need becomes almost a requirement. The same principle applies to mature markets when using terminology as a differentiation element.
|
|
312
|
312
|
|
|
313
|
313
|
BuildStream will have a glossary.
|
|
314
|
314
|
|
| ... |
... |
@@ -321,7 +321,7 @@ The FAQ is a relevant content element, often just appreciated by projects that h |
|
321
|
321
|
#### BuildStream outcomes (portfolio)
|
|
322
|
322
|
|
|
323
|
323
|
|
|
324
|
|
-Contents related with the different "products" offered by the BuildStream project. Each outcome should have a separated content page. So far, we have three different outcomes:
|
|
|
324
|
+Contents related with the different "products" offered by the BuildStream project. Each outcome should have a separate content page. So far, we have three different outcomes:
|
|
325
|
325
|
|
|
326
|
326
|
* Even releases: targeting users
|
|
327
|
327
|
* Odd releases: targeting testers (users and contributors)
|
| ... |
... |
@@ -330,7 +330,7 @@ Contents related with the different "products" offered by the BuildStream projec |
|
330
|
330
|
|
|
331
|
331
|
R.1 BuildStream releases: portfolio charter
|
|
332
|
332
|
|
|
333
|
|
-This page will have links to all the BuildStream releases, highlighting the current one, the ones maintained or recommended for the different profiles, together with the links to the complementary information that might be related to releases, like roadmap, announcements, etc.
|
|
|
333
|
+This page will have links to the BuildStream releases, highlighting the current one, the ones "in maintenance" and those recommended for the different target groups, together with the links to the complementary information that might be related to releases, like roadmap, announcements, etc.
|
|
334
|
334
|
|
|
335
|
335
|
|
|
336
|
336
|
R.2 Master
|
| ... |
... |
@@ -340,7 +340,7 @@ Master as such is not released but in BuildStream portfolio, it is the default o |
|
340
|
340
|
|
|
341
|
341
|
R.3 BuildStream releases feature page
|
|
342
|
342
|
|
|
343
|
|
-The feature page is the central page for each release, that contains the information about what is released, compared with previous releases. It also includes all the necessary links to have a wide view of how to evaluate consume and get community support for a specific release.
|
|
|
343
|
+The feature page is the central page for each release, that contains the information about what is released, compared with previous releases. It also includes all the necessary links to have a wide view of how to evaluate, consume and get community support for a specific release.
|
|
344
|
344
|
|
|
345
|
345
|
|
|
346
|
346
|
R.4 BuildStream deployment howto
|
| ... |
... |
@@ -388,7 +388,7 @@ One day BuildStream will dominate the world. We will be able to look at behavio |
|
388
|
388
|
|
|
389
|
389
|
To get there, we need to start today, simple but start.
|
|
390
|
390
|
|
|
391
|
|
-Having already defined our target audience to some extend was the first step. The content structure was the second one. The third one is to define our content considering a critical path, which is the journey we want to take our users through in order to consume our outcomes having a satisfactory experience. In other words, maximizing our conversion rate.
|
|
|
391
|
+Having already defined our target audience to some extent was the first step. The content structure was the second one. The third one is to define our content considering a critical path, which is the journey we want to take our users through in order to consume our outcomes having a satisfactory experience. In other words, maximizing our conversion rate.
|
|
392
|
392
|
|
|
393
|
393
|
In order to start simple, we will segment our audience in four groups, defining a critical path for each one of them. The target audiences are:
|
|
394
|
394
|
* People unaware of BuildStream
|
| ... |
... |
@@ -428,3 +428,5 @@ The following resources are recommended: |
|
428
|
428
|
|
|
429
|
429
|
[4] BuildStream_Content_Structure_all.pdf: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_all.pdf
|
|
430
|
430
|
|
|
|
431
|
+[5] https://en.wikipedia.org/wiki/Blue_Ocean_Strategy
|
|
|
432
|
+
|
