-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.qmd
82 lines (68 loc) · 3.58 KB
/
index.qmd
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
---
title: "Welcome to the Seedcase design documentation!"
about:
id: hero-heading
template: solana
image: _extensions/seedcase-project/seedcase-theme/logos/software-product-logos.svg
image-width: 10em
---
::: {#hero-heading}
This is the first place to look when trying to understand the Seedcase
framework and how it works from a high-level perspective.
The design
documentation is a way of providing an overall map of our software and
the principles we follow when developing it without getting into
specific technical details. It is also describes the goals,
general structure, requirements, and uses of the software to both
technical and non-technical users and stakeholders.
:::
{{< include /includes/_wip.qmd >}}
## Contents
The Seedcase framework is open-source software that interacts with data and aims to
have a user-interface designed to be
accessible. The design documentation is divided into four main sections:
- [Software architecture](software/index.qmd) documentation, which is
based on the [arc42](https://arc42.org) template and the [C4
Model](https://c4model.com/)
- [Data architecture](data/index.qmd) documentation, which is a
work-in-progress
- A [style guide](style/index.qmd), which is a work-in-progress
- An [accessibility guide](accessibility/index.qmd), which is a
work-in-progress
Along with the design documentation, we also document the decisions we
make in the [decisions](https://decisions.seedcase-project.org/)
archive. This is a place where we document the reasons behind the
decisions we make, and the trade-offs and alternatives we consider when
making those decisions.
## Reader
We've written these documents considering a few people in mind who will
read the documents:
- **New contributors/team members**: The most important reason we have
written design documentation is to quickly onboard new contributors
or team members to the project. We assume that they will likely read
all sections. Almost all of the documentation we write with these
readers in mind.
- **Other research software/data engineers**: These readers will be
interested in the much more technical aspects of the design
documentation, potentially for their own purposes, for learning, or
for modifying Seedcase software for their own project. We assume
they will read mostly the sections that get into the core details of
Seedcase products, so we write these sections with these readers
also in mind. These readers also include external consultants who
will act as expert reviewers of Seedcase software.
- **Technical stakeholders**: These are people, such as in IT units,
that have more technical knowledge and who are potentially involved
in approving software and helping with installing it. They are also
likely involved in dealing with any server-based errors that might
occur with Seedcase software, as well as any other software. They
might read the introduction sections as well as the slightly more
detailed sections, but likely not at the level of the previous two
readers.
- **Non-technical stakeholders**: This reader is any person who is
interested in understanding Seedcase products at more than a "How To
Install" and "How To Use" level, for instance to learn if a Seedcase
product is relevant for their work. This reader also includes our
external partners or those who want to learn a bit more about the
Seedcase Project after we've presented or advertised it. We assume
they will read mostly the introduction and first few sections, so we
try to write these sections with them in mind.