GNOME.org
 

[Notes] [Git][BuildStream/nosoftware/alignment][master] 14 commits: content structure proposal and associated diagrams in .pdf (vector) format

Title: GitLab

Agustin Benito Bethencourt pushed to branch master at BuildStream / nosoftware / alignment

Commits:

2 changed files:

Changes:

  • .gitlab/issue_templates/task.md
    ... ... @@ -17,6 +17,6 @@
    17 17 
     ----
    18 18
    19 19 
     /assign @toscalix
    20 
    -/milestone %"BuildStream_v1.1" %"BuildStream_v1.2"
    21 
    -/label ~Coordination ~Release ~Roadmap
    20 
    +/milestone %"BuildStream_v1.2" %"BuildStream_v1.4"
    21 
    +/label ~Coordination ~Release ~Roadmap ~Promotion
    22 22 
     /label ~Important ~Urgent ~Critical

  • content_design/content_structure_proposal_description.md
    ... ... @@ -2,13 +2,14 @@
    2 2
    3 3 
     In the same way that a software product requires an architecture, the contents of a product do too, for similar reasons, being scalability and maintainability two of the important ones.
    4 4
    5 
    -Based on previous experiences managing Open Source projects (products) I would like you to evaluate the following proposal which I've called "Content Structure". As usual, I am open to suggestions when it comes to naming.
    5 
    +I would like you to evaluate the following proposal which I've called "Content Structure". As usual, I am open to suggestions when it comes to naming.
    6 
    +
    7 
    +There are three diagrams[1,][2],[3] that support the current proposal. Please take a look at them before reading this document. One final document includes all of the three[4].
    6 8
    7 
    -There are three diagrams[1][2][3] that support the current proposal. Please take a look at them while reading this document. One final document includes all of the three[4].
    8 9
    9 10 
     ### Content Units
    10 11
    11 
    -The structure is based on related "Content Units", a name used to avoid the association of any of those units with a specific tool, the concept of a "page" or a "file".
    12 
    +The structure is based on "Content Units", a name used to avoid the association of any of those units with a specific tool, the concept of a "page" or a "file".
    12 13
    13 14 
     For example:
    14 15
    ... ... @@ -16,21 +17,19 @@ For example:
    16 17 
     * Two content units can be published initially in a single web page and, when they expand, separated into two.
    17 18
    18 19
    19 
    -I will refer to pages or files only  in specific cases.
    20 
    +I will refer to pages or files only  in specific cases.  The "Content Units" are grouped by topics and related. The relations are simple and will be developed in future diagrams.
    21 
    +
    20 22
    21 23 
     ### Target audience
    22 24
    23 
    -Based on the BuildStream target audience, I propose, for simplicity to consider the following target audience when it comes to content design:
    25 
    +Based on the BuildStream target audience, I propose for simplicity to consider the following target audiences when it comes to content design:
    24 26
    25 27 
     * Those unaware of the existence of BuildStream (99%)
    26 28 
     * Those aware of the existence of BuildStream (1%)
    27 29 
     	* BuildStream users (0.1%)
    28 
    -		* BuildStream contributors (0.01%)
    29 
    -
    30 
    -
    31 
    -In general, when I refer to users, I will also be referring to contributors.
    30 
    +		* BuildStream contributors (0.001%)
    32 31
    33 
    -As the project, so the content, matures, it would be ideal to segment some of the above target audiences.
    32 
    +Inmost occasions when I refer to users, I will also be referring to contributors. As the project, so the content, matures, it would be ideal to segment some of the above target audiences.
    34 33
    35 34 
     Occasionally, the proposal or/and content itself might refer to the following subgroups:
    36 35
    ... ... @@ -41,38 +40,39 @@ Occasionally, the proposal or/and content itself might refer to the following su
    41 40 
     	* Core contributors: those who contribute on regular basis, normally to specific/key areas.
    42 41 
     	* Occasional, sporadic, opportunistic contributors: the rest of the contributors.
    43 42
    44 
    -
    45 43 
     This might provide a hint on further target audience segmentation we can define in the coming future.
    46 44
    45 
    +
    47 46 
     ### Tools
    48 47
    49 48 
     Initially we will work with what we have:
    50 49
    51 
    -* The GNOME wiki
    52 50 
     * Gitlab:
    53 51 
     	* The current guide.
    54 52 
     	* Key files in repos (specially buildstream.
    53 
    +* The GNOME wiki
    55 54
    56 55
    57 56 
     The structure is designed to be as "tool agnostic" as possible.
    58 57
    59 
    -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 get ready for when a web comes reducing the effort that keeping the information on the wiki and git on sync.
    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 
    +
    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.
    60 61
    61 
    -One risk we need to strongly consider is related with the links strategy. There are several ways to approach this issue and it will be a matter of policy. Breaking links might through to the garbage not just internal references, so out pre-defined critical paths, but also external references to our content.
    62 62
    63 63 
     ### Timeline
    64 64
    65 
    -Ideally, we will have those contents directly related with the release ready for the Release Date (RD) and the rest would be done little by little, having ELCE 2018 as a key milestone.
    65 
    +Ideally, we will have most of the content units directly related with the BuildStream 1.2 release ready for the Release Date (RD). The rest will be done little by little, having ELCE 2018 as a key milestone.
    66 
    +
    66 67
    67 68 
     ### Content management
    68 69
    69 
    -Since this is an Open Source project, the best way to receive meaningful contributions in this area is to define the structure, create minimal contents based on the structure for at least the essential units and provide the community some guidelines on how to contribute. This will be the approach I propose to follow vs the approach in which contents are only published when finished.
    70 
    +Since BuildStream is an Open Source project, a proven way to receive meaningful contributions in contents is to define the structure, create minimal contents according to that structure and point to missing content together with simple and clear policies on how to contribute. This will be the approach I propose to follow vs the approach in which contents are only published when finished.
    70 71
    71 
    -As you already know by now, if we want good contents we will need to be as serious about them as we are about code. We have a good example on the current guide. We will create a web repo in nosoftware subgroup including a bug tracked about it. A proposal on how to relate this ticketing system with the existing ones and the current Documentation label will be sent to the list.
    72 
    +As you already know by now, if we want good contents we should be as serious about them as we are about code. We have a good example on the current guide. We will create a web repo in nosoftware subgroup including a bug tracked for the contents. A proposal on how to relate this ticketing system with the existing ones and the current Documentation label will be sent to the list.
    72 73
    73 
    -A key part of the maintainability story when it comes to content are labels/tags and URLs. We will need to pay special attention to them and create very specific policies on how to create and update them.
    74 
    +A key part of the maintainability story when it comes to contents are labels/tags and URLs. We will need to pay special attention to them and create very specific policies on how to create and update them.
    74 75
    75 
    -Except the front page of the wiki, we will focus initially on the release related content. Before ELCE 2018, we will put additional effort on the wiki.
    76 76
    77 77 
     ### Criteria followed to structure the content units
    78 78
    ... ... @@ -82,9 +82,7 @@ Assuming the Open Source nature of the project and the fact that we are developi
    82 82 
     #### Expected content change rate
    83 83
    84 84
    85 
    -Some content units will have a higher change rate than others. Separate them in different content units is essential to reduce in the future the maintenance effort. It also helps to decide which tool could appropriate for each unit too.
    86 
    -
    87 
    -For simplicity, I have considered the following groups:
    85 
    +Some content units will have a higher change rate than others. Separate them in different content units is essential to reduce in the future the maintenance effort. It also helps to decide which tool could be appropriate for each unit. For simplicity, I have only considered the following groups:
    88 86
    89 87 
     * (almost) Static: content that is not expected to change frequently, i.e. project principles or Manifest.
    90 88 
     * Dynamic: content that is expected to change frequently, grow overtime or have a limited life expectancy.
    ... ... @@ -95,23 +93,22 @@ For simplicity, I have considered the following groups:
    95 93 
     #### Front page vs project and landing pages
    96 94
    97 95
    98 
    -There are two main content units we will used as "root units" in terms of the proposed content structure:
    96 
    +There are two main content units we will use as "root units":
    99 97
    100 98 
     * Project page.
    101 99 
     * Landing page.
    102 100
    103 101
    104 
    -I refer to them as pages, instead of units, because they are single pages and also because is a very common terminology.
    105 
    -
    106 
    -Please be aware that these pages will not be designed as the BuildStream project front page (also common terminology). Until we have a web (hopefully for ELCE 2018) we will have a simple front page on the wiki, as today, which will be designed to die (erasable).
    102 
    +I refer to them as pages, instead of units, because they are single pages and also because the names are popular among those who develop FLOSS "products".
    107 103
    108 
    -The project page and the landing page might be moved to the future web, depending on design, effort and maintenance related decisions. Based on it, the current wiki front page (project wiki page in GNOME terminology) might change.
    104 
    +Please be aware that these pages will not be designed as the BuildStream front/home page.
    109 105
    106 
    +The project page and the landing page might be moved to the future web, depending on design, effort and maintenance factors.
    110 107
    111 
    -#### Outcomes as the most influential event
    112 108
    109 
    +#### Releases of outcomes drive the content structure
    113 110
    114 
    -Assuming the normal journey to become a maintainer:
    111 
    +Assuming the most common journey to become a maintainer (not the only one) being:
    115 112
    116 113 
     Humanity -> User -> Power user -> Occasional Contributor -> Core contributor -> Maintainer
    117 114
    ... ... @@ -119,44 +116,44 @@ at this point of maturity of the project, releases allow us to maximize the impa
    119 116
    120 117 
     As the project matures and the number of users grow we might evolve our focus towards gaining contributors, for instance. The structure, with the support of the critical path definitions, should evolve too.
    121 118
    122 
    -In my experience, using the concept of releases as criteria for defining the content structure of projects that:
    119 
    +In my experience, using the concept of releases as criteria for defining the content structure in projects that:
    123 120
    124 
    -* Need the kind of attention that leads them to find users with technical profile.
    121 
    +* Need the kind of attention that leads them to find users with technical skills.
    125 122 
     * Does not have a meaningful number of experienced technical product content creators.
    126 123 
     * Cannot or do not want to heavily invest in promotion/marketing activities compared to development ones.
    127 124
    128 125
    129 
    -.... work well.
    126 
    +.... work well.
    130 127
    131 128
    132 
    -#### Use cases and sister projects
    129 
    +#### Other user and sister projects
    133 130
    134 131
    135 132 
     BuildGrid has been considered as a "sister project". Initially, it can rely of the current structure to minimize the effort required from their side.
    136 133
    137 134 
     Freedesktop-SDK can be considered explicitly in several units, like in Pr.1 D.1, D.4 and D.5 There is plenty of room for collaboration.
    138 135
    139 
    -Additional use cases can also be considered in several units. I hope you agree with me that the proposed structure leaves enough room to accommodate them. Otherwise, please let me know.
    136 
    +Additional user projects can also be considered in several units. I hope you agree with me that the proposed structure leaves enough room to accommodate them. Otherwise, please let me know.
    140 137
    141 138 
     ### Topic
    142 139
    143 
    -The content has been structured in 6 different groups based on topic. Some units might be part of several  groups so please point out  when you feel the grouping might be too controversial. this grouping helps to structure the proposal but it has no direct relation with how the final "pages" are linked in most cases. Please check the BuildStream_Content_Structure_diagram.pdf image[1].
    140 
    +The content has been structured in 6 different topic groups. Some units might belong to more than one. The intention is to be clear, not accurate. The current grouping has a small impact on how the final "pages" are linked in most cases. Please check the BuildStream_Content_Structure_diagram.pdf image[1].
    144 141
    145 142 
     The topics are:
    146 143
    147 
    -* Community (Pj - project): content related with the community project, not necessarily with the outcome of the project.
    148 
    -* Management  (M): content related with the management of the roadmap, development and delivery of the outcomes of the project.
    149 
    -* Promotion: content related with the promotion of the project in general, and the activities involved in producing the outcomes in particular.
    150 
    -* Code and metadata: content units directly related with the code and metadata.
    151 
    -* BuildStream description: content  units related with the description of the outcomes and some  specific content that helps  in consumption and community support activities.
    152 
    -* Outcomes: contents directly related with the outcomes that are "released" and/or consumed by users.
    144 
    +* Community (Pj - project): content related with the community project, its governance and participants.
    145 
    +* Management  (M): content related with the management of the roadmap, development and delivery of the project outcomes.
    146 
    +* Promotion: content related with the promotion of the different outcomes and activities generated by the BuildStream community.
    147 
    +* Code and metadata: content units directly related with the code and metadata. Please be aware that some might consider the code itself as "the content".
    148 
    +* BuildStream description: content  units related with the description of the outcomes together with some additional information that helps to consume them.
    149 
    +* Outcomes: contents directly related with the BuildStream outcomes that are "released" and/or consumed by users.
    153 150 
     * Landing page and project page: root pages of the key/essential content with a very specific purpose.
    154 151
    155 152
    156 153 
     ### Content structure description
    157 154
    158 155
    159 
    -Please check the diagram called BuildStream Content Structure, which is the first page of the attached .pdf file. You can also find the image in the gitlab[1]
    156 
    +Please check the diagram[1] called BuildStream Content Structure. The following section is a description of the diagram.
    160 157
    161 158
    162 159 
     #### 0. BuildStream tool landing page
    ... ... @@ -171,14 +168,10 @@ This would be the starting point for those looking for a general definition of w
    171 168 
     This would be the starting/root point for those contents related with the BuildStream Open Source project.
    172 169
    173 170
    174 
    -#### C. BuildStream Code ==
    175 
    -
    171 
    +#### C. BuildStream Code
    176 172
    177 
    -There is a well documented by now change in behavior when it comes to content consumption related with Open Source projects that favors for certain profiles specific repo files over content in other platforms, specially when the information is tightly related with the code.
    178 173
    179 
    -For complex and bigger project this trend represents a challenge since involves content maintenance related risks (inconsistency, duplication, outdated info...), specially when other content platforms are not git based, like in our case, where the GNOME wiki pages are editable.
    180 
    -
    181 
    -In terms of design, we will need to consider the following, to mitigate such risks:
    174 
    +Together with the Download page, the following gitlab files are essential:
    182 175
    183 176 
     * README files will be nothing but a summary of what is present in other pages. Links to those pages will be included in the README file and will need to be maintained.
    184 177 
     * BuildStream will have the README file of the master branch as the entry point for contributors, instead of Master (outcome) unit initially. As the tool grows and becomes more mature, this decision might change.
    ... ... @@ -188,53 +181,55 @@ In terms of design, we will need to consider the following, to mitigate such ris
    188 181 
     	* C.4 News/Release notes file - R.3 Feature page and D. BuildStream In Detail content units.
    189 182 
     	* C.5 Maintainers - Pj.5 Community support and Tools content unit.
    190 183
    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.
    191 185
    192 186 
     C.1 BuildStream download page
    193 187
    194 188 
     The Download page is the central reference not just to download the outcomes delivered by the project, but also the associated metadata. It will also have structured and direct references to all the information required to have a smooth deployment/installation experience.
    195 189
    196 
    -The structure of this unit will consider:
    190 
    +This unit will include, at least, the following content:
    197 191
    198 192 
     * Versioning.
    199 193 
     * Platforms where BuildStream is expected to be installed.
    200 194 
     * Deployment mechanisms/technologies.
    201 195 
     * Complementary plugins and tools required for the deployment/installation/usage of BuildStream.
    202 
    -* Additional content units that any user needs  to consider.
    196 
    +* Additional content units that any user needs to consider.
    203 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.
    204 198
    205 199
    206 
    -C.2 Release branch and master README file
    200 
    +C.2 README files
    207 201
    208 
    -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):
    209 203
    210 204 
     * Documentation - D. BuildStream in detail unit
    211 205 
     * Community support (get help) - D.5 FAQ.
    212 206 
     * Contributing - Pj.3 How to contribute unit.
    213 207 
     * Licensing and copyrights - C.3 LICENSE and Pj.2 Governance+license+sponsors
    214 208
    215 
    -
    216 209 
     Relations: C.2 README.rst - R.2 Master, 0. Landing Page, R.3 Feature Page and R.4 Deployment Howto units.
    217 210
    218 
    -C.3 Release branch and master Copying/LICENSE file
    211 
    +
    212 
    +C.3 COPYING/LICENSE file
    219 213
    220 214 
     This unit should include:
    221 215
    222 216 
     * Project license. Explicit description. Links.
    223 217 
     * Exceptions (if any) that are included in the repo. Explicit description. Links.
    224 218
    225 
    -
    226 219 
     Relations: C.3 LICENSE file - Pj.2 Governance+license+sponsors content units. A complementary proposal related with compliance will be sent.
    227 220
    228 
    -C.4 Release branch and Master (dev releases) NEWS/Release Notes.
    229 221
    230 
    -News related with each release (digested release notes). Further content can be considered in this unit or separate ones like:
    222 
    +C.4 NEWS/Release Notes file.
    223 
    +
    224 
    +News related with each release (digested release notes). Further information can be considered in this content unit or new one like:
    231 225
    232 226 
     * Changelog
    233 227 
     * Raw release notes.
    234 228
    235 229 
     Relations: C.4 News/Release notes file - R.3 Feature page and D. BuildStream In Detail content units.
    236 230
    237 
    -C.5 Release branch and master Maintainers file
    231 
    +
    232 
    +C.5 Maintainers file
    238 233
    239 234 
     List of maintainers, responsibility and contact.
    240 235
    ... ... @@ -298,7 +293,7 @@ It is important to link the feature descriptions to code, so the content is wort
    298 293
    299 294 
     D.1 Integrate with BuildStream: examples
    300 295
    301 
    -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.
    302 297
    303 298
    304 299 
     D.2 BuildStream plug-ins and other complementary features
    ... ... @@ -313,7 +308,7 @@ Detailed description of the core features shipped by BuildStream, including thos
    313 308
    314 309 
     D.4 BuildStream glossary
    315 310
    316 
    -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.
    317 312
    318 313 
     BuildStream will have a glossary.
    319 314
    ... ... @@ -326,7 +321,7 @@ The FAQ is a relevant content element, often just appreciated by projects that h
    326 321 
     #### BuildStream outcomes (portfolio)
    327 322
    328 323
    329 
    -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:
    330 325
    331 326 
     * Even releases: targeting users
    332 327 
     * Odd releases: targeting testers (users and contributors)
    ... ... @@ -335,7 +330,7 @@ Contents related with the different "products" offered by the BuildStream projec
    335 330
    336 331 
     R.1 BuildStream releases: portfolio charter
    337 332
    338 
    -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.
    339 334
    340 335
    341 336 
     R.2 Master
    ... ... @@ -345,7 +340,7 @@ Master as such is not released but in BuildStream portfolio, it is the default o
    345 340
    346 341 
     R.3 BuildStream releases feature page
    347 342
    348 
    -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.
    349 344
    350 345
    351 346 
     R.4 BuildStream deployment howto
    ... ... @@ -393,7 +388,7 @@ One day BuildStream will dominate the world. We will be able to look at behavio
    393 388
    394 389 
     To get there, we need to start today, simple but start.
    395 390
    396 
    -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.
    397 392
    398 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:
    399 394 
     * People unaware of BuildStream
    ... ... @@ -412,7 +407,7 @@ Each content unit is related with the one described in the content structure. O
    412 407 
     We will need to answer to following questions: are the BuildStream content helping to move people away from the Unaware group into the contributors segment group?
    413 408
    414 409 
     Which means that we need a way to evaluate if the content structure, the content themselves and the critical paths work as expected. There are tools that provide metrics and dashboards to analyze the potential answers to these questions. Before we get to this point, we can evaluate the following:
    415 
    -* Number of downloads of BuildStream..
    410 
    +* Number of downloads of BuildStream.
    416 411 
     * Number of regular updates of BuildStream.
    417 412 
     * Hits per page.
    418 413 
     * Permanence time per page.
    ... ... @@ -424,7 +419,14 @@ which will provide us enough information to start learning about how well are we
    424 419 
     ## Further resources
    425 420
    426 421 
     The following resources are recommended:
    427 
    -[1] BuildStream_Content_Structure_diagram.pdf:
    428 
    -[2] BuildStream_Content_Structure_critical_path_per_target.pdf:
    429 
    -[3] BuildStream_Content_Structure_critical_path.pdf:
    430 
    -[4] BuildStream_Content_Structure_all.pdf:
    422 
    +
    423 
    +[1] BuildStream_Content_Structure_diagram.pdf: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_diagram.pdf
    424 
    +
    425 
    +[2] BuildStream_Content_Structure_critical_path_per_target.pdf: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_critical_path_per_target.pdf
    426 
    +
    427 
    +[3] BuildStream_Content_Structure_critical_path.pdf: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_critical_path.pdf
    428 
    +
    429 
    +[4] BuildStream_Content_Structure_all.pdf: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_all.pdf
    430 
    +
    431 
    +[5] https://en.wikipedia.org/wiki/Blue_Ocean_Strategy
    432 
    +

    • —
    View it on GitLab.
    You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.

    [Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]