-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathDesignDocumentGuides.html
More file actions
668 lines (523 loc) · 33.1 KB
/
Copy pathDesignDocumentGuides.html
File metadata and controls
668 lines (523 loc) · 33.1 KB
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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
<!DOCTYPE html>
<html lang="en" data-content_root="./" >
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Design Document Guidelines — MantidProject main documentation</title>
<script data-cfasync="false">
document.documentElement.dataset.mode = localStorage.getItem("mode") || "";
document.documentElement.dataset.theme = localStorage.getItem("theme") || "";
</script>
<!--
this give us a css class that will be invisible only if js is disabled
-->
<noscript>
<style>
.pst-js-only { display: none !important; }
</style>
</noscript>
<!-- Loaded before other Sphinx assets -->
<link href="_static/styles/theme.css?digest=a95f357e85573c9b56d5" rel="stylesheet" />
<link href="_static/styles/pydata-sphinx-theme.css?digest=a95f357e85573c9b56d5" rel="stylesheet" />
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=03e43079" />
<link rel="stylesheet" type="text/css" href="_static/css/style.css?v=562d7d41" />
<!-- So that users can add custom icons -->
<script defer src="_static/scripts/fontawesome.js?digest=a95f357e85573c9b56d5"></script>
<!-- Pre-loaded scripts that we'll load fully later -->
<link rel="preload" as="script" href="_static/scripts/bootstrap.js?digest=a95f357e85573c9b56d5" />
<link rel="preload" as="script" href="_static/scripts/pydata-sphinx-theme.js?digest=a95f357e85573c9b56d5" />
<script src="_static/documentation_options.js?v=a8da1a53"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<script>DOCUMENTATION_OPTIONS.pagename = 'DesignDocumentGuides';</script>
<script>DOCUMENTATION_OPTIONS.search_as_you_type = false;</script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Generating code coverage" href="CodeCoverage.html" />
<link rel="prev" title="Technical Steering Committee" href="TSC.html" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="docsearch:language" content="en">
<link rel="icon" sizes="32x32" href="_static/images/favicon.ico">
</head>
<body data-default-mode="">
<div id="pst-skip-link" class="skip-link d-print-none"><a href="#main-content">Skip to main content</a></div>
<div id="pst-scroll-pixel-helper"></div>
<button type="button" class="btn rounded-pill" id="pst-back-to-top">
<i class="fa-solid fa-arrow-up"></i>Back to top</button>
<dialog id="pst-search-dialog">
<form class="bd-search d-flex align-items-center"
action="search.html"
method="get">
<i class="fa-solid fa-magnifying-glass"></i>
<input type="search"
class="form-control"
name="q"
placeholder="Search the docs ..."
aria-label="Search the docs ..."
autocomplete="off"
autocorrect="off"
autocapitalize="off"
spellcheck="false"/>
<span class="search-button__kbd-shortcut"><kbd class="kbd-shortcut__modifier">Ctrl</kbd>+<kbd>K</kbd></span>
</form>
</dialog>
<div class="pst-async-banner-revealer d-none">
<aside id="bd-header-version-warning" class="d-none d-print-none" aria-label="Version warning"></aside>
</div>
<header id="pst-header" class="bd-header navbar navbar-expand-lg bd-navbar d-print-none">
<div class="bd-header__inner bd-page-width">
<button class="pst-navbar-icon sidebar-toggle primary-toggle" aria-label="Site navigation">
<span class="fa-solid fa-bars"></span>
</button>
<div class="col-lg-3 navbar-header-items__start">
<div class="navbar-item">
<a class="navbar-brand logo" href="index.html">
<img src="_static/images/mantid_logo_light.png" class="logo__image only-light" alt="Logo image">
<img src="_static/images/mantid_logo_dark.png" class="logo__image only-dark" alt="Logo image">
</a></div>
</div>
<div class="col-lg-9 navbar-header-items">
<div class="me-auto navbar-header-items__center">
<div class="navbar-item"><ul id="navbar-main-elements" class="navbar-nav">
<li class="nav-item">
<a class="reference internal nav-link" href="https://download.mantidproject.org">Downloads</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org/nightly/tutorials/">Tutorials</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org">User Docs</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://developer.mantidproject.org">Develop</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org/release/">Release notes</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://www.mantidproject.org/contact">Contact Us</a>
</li>
</ul></div>
</div>
<div class="navbar-header-items__end">
<div class="navbar-item navbar-persistent--container">
<button class="btn search-button-field search-button__button pst-js-only" title="Search" aria-label="Search" data-bs-placement="bottom" data-bs-toggle="tooltip">
<i class="fa-solid fa-magnifying-glass"></i>
<span class="search-button__default-text">Search</span>
<span class="search-button__kbd-shortcut"><kbd class="kbd-shortcut__modifier">Ctrl</kbd>+<kbd class="kbd-shortcut__modifier">K</kbd></span>
</button>
</div>
<div class="navbar-item">
<div class="theme-switch-container dropdown pst-js-only" data-bs-toggle="tooltip" data-bs-placement="bottom" title="Color mode">
<button class="btn btn-sm nav-link pst-navbar-icon theme-switch-button dropdown-toggle" aria-label="Color mode" data-bs-toggle="dropdown">
<i class="theme-switch fa-solid fa-sun fa-lg fa-fw" data-mode="light" title="Light"></i>
<i class="theme-switch fa-solid fa-moon fa-lg fa-fw" data-mode="dark" title="Dark"></i>
<i class="theme-switch fa-solid fa-circle-half-stroke fa-lg fa-fw" data-mode="auto" title="System Settings"></i>
</button>
<ul class="dropdown-menu dropdown-menu-end">
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="auto"><i class="fa-solid fa-circle-half-stroke fa-lg fa-fw me-1"></i>System Settings</button></li>
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="light"><i class="fa-solid fa-sun fa-lg fa-fw me-1"></i>Light</button></li>
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="dark"><i class="fa-solid fa-moon fa-lg fa-fw me-1"></i>Dark</button></li>
</ul>
</div></div>
<div class="navbar-item"><ul id="navbar-icon-links" class="navbar-nav" aria-label="Icon Links">
<li class="nav-item">
<a class="nav-link" href="https://github.com/mantidproject/mantid" rel="noopener" target="_blank" title="GitHub">
<span><i class="fab fa-github-square"></i></span>
<label class="sr-only">GitHub</label>
</a>
</li>
</ul></div>
</div>
</div>
<div class="navbar-persistent--mobile">
<button class="btn search-button-field search-button__button pst-js-only" title="Search" aria-label="Search" data-bs-placement="bottom" data-bs-toggle="tooltip">
<i class="fa-solid fa-magnifying-glass"></i>
<span class="search-button__default-text">Search</span>
<span class="search-button__kbd-shortcut"><kbd class="kbd-shortcut__modifier">Ctrl</kbd>+<kbd class="kbd-shortcut__modifier">K</kbd></span>
</button>
</div>
<button class="pst-navbar-icon sidebar-toggle secondary-toggle" aria-label="On this page">
<span class="fa-solid fa-outdent"></span>
</button>
</div>
</header>
<div class="bd-container">
<div class="bd-container__inner bd-page-width">
<dialog id="pst-primary-sidebar-modal"></dialog>
<div id="pst-primary-sidebar" class="bd-sidebar-primary bd-sidebar">
<div class="sidebar-header-items sidebar-primary__section">
<div class="sidebar-header-items__center">
<div class="navbar-item"><ul id="navbar-main-elements" class="navbar-nav">
<li class="nav-item">
<a class="reference internal nav-link" href="https://download.mantidproject.org">Downloads</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org/nightly/tutorials/">Tutorials</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org">User Docs</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://developer.mantidproject.org">Develop</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://docs.mantidproject.org/release/">Release notes</a>
</li>
<li class="nav-item">
<a class="reference internal nav-link" href="https://www.mantidproject.org/contact">Contact Us</a>
</li>
</ul></div>
</div>
<div class="sidebar-header-items__end">
<div class="navbar-item">
<div class="theme-switch-container dropdown pst-js-only" data-bs-toggle="tooltip" data-bs-placement="bottom" title="Color mode">
<button class="btn btn-sm nav-link pst-navbar-icon theme-switch-button dropdown-toggle" aria-label="Color mode" data-bs-toggle="dropdown">
<i class="theme-switch fa-solid fa-sun fa-lg fa-fw" data-mode="light" title="Light"></i>
<i class="theme-switch fa-solid fa-moon fa-lg fa-fw" data-mode="dark" title="Dark"></i>
<i class="theme-switch fa-solid fa-circle-half-stroke fa-lg fa-fw" data-mode="auto" title="System Settings"></i>
</button>
<ul class="dropdown-menu dropdown-menu-end">
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="auto"><i class="fa-solid fa-circle-half-stroke fa-lg fa-fw me-1"></i>System Settings</button></li>
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="light"><i class="fa-solid fa-sun fa-lg fa-fw me-1"></i>Light</button></li>
<li><button class="dropdown-item d-flex align-items-center theme-change-button" data-mode="dark"><i class="fa-solid fa-moon fa-lg fa-fw me-1"></i>Dark</button></li>
</ul>
</div></div>
<div class="navbar-item"><ul id="navbar-icon-links" class="navbar-nav" aria-label="Icon Links">
<li class="nav-item">
<a class="nav-link" href="https://github.com/mantidproject/mantid" rel="noopener" target="_blank" title="GitHub">
<span><i class="fab fa-github-square"></i></span>
<label class="sr-only">GitHub</label>
</a>
</li>
</ul></div>
</div>
</div>
<div class="sidebar-primary-items__start sidebar-primary__section">
<div class="sidebar-primary-item pst-sidebar-collapse"><button id="pst-collapse-sidebar-button" aria-expanded="true" aria-controls="pst-primary-sidebar"><svg class="pst-icon svg-inline--fa" role="img" aria-hidden="true" focusable="false" viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">
<path fill="currentColor" d="M3 15.5C2.36232 15.5 1.74874 15.2564 1.28478 14.8189C0.820828 14.3815 0.541576 13.7832 0.504167 13.1467L0.5 13L0.5 3C0.499965 2.36232 0.743605 1.74874 1.18107 1.28478C1.61854 0.820828 2.21676 0.541576 2.85333 0.504167L3 0.5L13 0.5C13.6377 0.499965 14.2513 0.743605 14.7152 1.18107C15.1792 1.61854 15.4584 2.21676 15.4958 2.85333L15.5 3L15.5 13C15.5 13.6377 15.2564 14.2513 14.8189 14.7152C14.3815 15.1792 13.7832 15.4584 13.1467 15.4958L13 15.5L3 15.5ZM3 13.8333L10.5 13.8333L10.5 2.16667L3 2.16667C2.79589 2.16669 2.59889 2.24163 2.44636 2.37726C2.29383 2.5129 2.19638 2.69979 2.1725 2.9025L2.16667 3L2.16667 13C2.16669 13.2041 2.24163 13.4011 2.37726 13.5536C2.5129 13.7062 2.69979 13.8036 2.9025 13.8275L3 13.8333ZM6.65583 10.325L6.5775 10.2558L4.91083 8.58917C4.76735 8.44567 4.68116 8.25476 4.66843 8.05223C4.65569 7.84971 4.71729 7.6495 4.84167 7.48917L4.91083 7.41083L6.5775 5.74417C6.72747 5.59471 6.9287 5.50794 7.14032 5.50148C7.35194 5.49502 7.55809 5.56935 7.7169 5.70937C7.8757 5.8494 7.97525 6.04463 7.99533 6.25539C8.01541 6.46616 7.95451 6.67667 7.825 6.84417L7.75583 6.9225L6.67917 8L7.75583 9.0775C7.89931 9.22099 7.98551 9.41191 7.99824 9.61443C8.01097 9.81695 7.94938 10.0172 7.825 10.1775L7.75583 10.2558C7.61234 10.3993 7.42142 10.4855 7.2189 10.4982C7.01638 10.511 6.81617 10.4494 6.65583 10.325Z"/>
</svg>
<span class="pst-collapse-sidebar-label">Collapse Sidebar</span>
<span class="pst-expand-sidebar-label">Expand Sidebar</span>
</button></div>
<div class="sidebar-primary-item">
<nav class="bd-docs-nav bd-links"
aria-label="Section Navigation">
<p class="bd-links__title" role="heading" aria-level="1">Section Navigation</p>
<div class="bd-toc-item navbar-nav"></div>
</nav></div>
</div>
<div class="sidebar-primary-items__end sidebar-primary__section">
<div class="sidebar-primary-item">
<div id="ethical-ad-placement"
class="flat"
data-ea-publisher="readthedocs"
data-ea-type="readthedocs-sidebar"
data-ea-manual="true">
</div></div>
</div>
</div>
<main id="main-content" class="bd-main" role="main">
<div class="bd-content">
<div class="bd-article-container">
<div class="bd-header-article d-print-none">
<div class="header-article-items header-article__inner">
<div class="header-article-items__start">
<div class="header-article-item">
<nav aria-label="Breadcrumb" class="d-print-none">
<ul class="bd-breadcrumbs">
<li class="breadcrumb-item breadcrumb-home">
<a href="index.html" class="nav-link" aria-label="Home">
<i class="fa-solid fa-home"></i>
</a>
</li>
<li class="breadcrumb-item active" aria-current="page"><span class="ellipsis">Design Document Guidelines</span></li>
</ul>
</nav>
</div>
</div>
</div>
</div>
<div id="searchbox"></div>
<article class="bd-article">
<section id="design-document-guidelines">
<span id="designdocumentguidelines"></span><h1>Design Document Guidelines<a class="headerlink" href="#design-document-guidelines" title="Link to this heading">#</a></h1>
<p>A good design document minimises unexpected complications by addressing
them before the code is written. A document will provide you, your
manager and your team with a common vocabulary for talking about the
project. Writing an effective design document can be tricky in itself, as
they often add unnecessary complexity if not done with care. These
guidelines are to help with when and how to generate effective and simple design
documents.</p>
<section id="when-to-write-a-design-document">
<h2>When to write a design document<a class="headerlink" href="#when-to-write-a-design-document" title="Link to this heading">#</a></h2>
<p>This section provides some guidelines on when to produce a design document.
Note that, it is not about when to do a design and when not.
Except for trivial changes, one should always perform design work before coding, no matter the scope or the nature of the feature.
These guidelines set out in which cases the design must be a <em>public</em>, <em>written</em> and <em>persistent</em> document, rather than a sketch on a white-board in a stand-up meeting.
Just like coding, design is an iterative and collaborative process.
Having a written document allows for discussion and iterations with peers, including across facilities, before the first line of code is typed.
Besides, the written document facilitates the pull request review process.
Having the design already approved, the reviewer will not need to do a design review with the code review, but will just need to make sure that the implementation matches the previously agreed design.
Finally, once written, the document can also serve as (or easily be turned into) a developer documentation for future reference.</p>
<p>Not every feature requires a design document. The benefit it adds must be gauged with the time and effort that goes into it.
Below are the main scenarios when a design document is necessary or not.</p>
<div class="pst-scrollable-table-container"><table class="table">
<thead>
<tr class="row-odd"><th class="head"><p>Design Document Needed</p></th>
<th class="head"><p>Design Document Not Needed</p></th>
</tr>
</thead>
<tbody>
<tr class="row-even"><td><ul class="simple">
<li><p>Large-scope feature - e.g. slice viewer, instrument viewer</p></li>
<li><p>Brand-new feature - e.g. crash reporter, plot manager</p></li>
<li><p>Core refactors - e.g. HistogramData, DetectorInfo</p></li>
<li><p>Abstractions, APIs - e.g. simpleapi, a new workspace type</p></li>
<li><p>Fully fledged libraries - e.g. Crystal library in the framework</p></li>
</ul>
</td>
<td><ul class="simple">
<li><p>Bug fixes of any kind</p></li>
<li><p>Minor extensions to the current tools - e.g. adding another button in a GUI widget</p></li>
<li><p>New functionalities to an extant algorithm – e.g. another target of unit conversion</p></li>
<li><p>Concrete, single-class plugins - e.g. a new algorithm or a new fit function</p></li>
</ul>
</td>
</tr>
</tbody>
</table>
</div>
<p>Below are a handful of measurable quantities that could help a developer decide which category the feature belongs to.</p>
<section id="amount-of-classes">
<h3>Amount of classes<a class="headerlink" href="#amount-of-classes" title="Link to this heading">#</a></h3>
<p>Single-class plugins, such as algorithms, do not require design documents.
In the contrary, if the number of classes is more than a dozen, the document could be relevant in order to describe the relations between them.</p>
</section>
<section id="amount-of-files">
<h3>Amount of files<a class="headerlink" href="#amount-of-files" title="Link to this heading">#</a></h3>
<p>If the feature intends to touch (add or edit) a single file, design document is not needed.
If it is more than a hundred, opposite is likely the case.</p>
</section>
<section id="abstractness-fraction">
<h3>Abstractness fraction<a class="headerlink" href="#abstractness-fraction" title="Link to this heading">#</a></h3>
<p>Stability of a piece of code must be proportional to its abstractness; abstractions and APIs are hard to change, once in.
So whenever the feature concerns creations of new abstraction layers and APIs, a wider discussion on the design is needed, hence the necessity of the document.
A good measure for this is the intended fraction of the abstract classes (virtual or pure virtual) in the design.</p>
</section>
<section id="the-layer-of-intent">
<h3>The layer of intent<a class="headerlink" href="#the-layer-of-intent" title="Link to this heading">#</a></h3>
<p>If the feature is deep in the framework or workbench, it is more critical to have a document.
Features in the core layer must be carefully thought out, as many other things will depend on them.
In the contrary, if the feature is just a plugin in the periphery (algorithm, function, GUI, script), with low risk of side effects, a design document is less important.</p>
</section>
<section id="number-of-developers">
<h3>Number of developers<a class="headerlink" href="#number-of-developers" title="Link to this heading">#</a></h3>
<p>If the feature is large enough that the implementation will be done in a distributed way (i.e. more than one developer), the document will ensure that the whole team has a common vision, discussed and agreed upfront.</p>
</section>
<section id="number-of-users">
<h3>Number of users<a class="headerlink" href="#number-of-users" title="Link to this heading">#</a></h3>
<p>If the feature is generic, it will be facing a wider audience of users, hence a document and design review will make sure that the right feature is being built in the right way.
In the contrary, if the feature is specific to one instrument or technique at one facility, producing a document is less important.</p>
</section>
<section id="number-of-person-months">
<h3>Number of person-months<a class="headerlink" href="#number-of-person-months" title="Link to this heading">#</a></h3>
<p>Another metric could be the estimated effort in person-months. If the feature is estimated to take a year to develop, it is worth spending a few weeks to iterate and improve on the design.
If the feature is less than one month of work, it’s probably an overkill.</p>
<p>These are just guidelines and not strict rules.
It is hard to define exact thresholds on these quantities, and often your feature is going to be in a grey zone anyway.
Therefore, it is advised to combine all these metrics and make a professional judgement on a case-by-case basis.
Nevertheless, a good intuition on when a document is useful, and when not, comes with experience.
That’s why, whenever in doubt, get in touch with the senior members of the team - the gatekeepers.
A good first contact could be the local team lead at your facility, or the <em>tech-qa</em> channel on slack.</p>
</section>
</section>
<section id="design-document-process">
<h2>Design document process<a class="headerlink" href="#design-document-process" title="Link to this heading">#</a></h2>
<p>Once identified that for a given feature a design document is needed, the process goes as follows:</p>
<ol class="arabic simple">
<li><p>Create an item in the technical working group roadmap <a class="reference external" href="https://github.com/mantidproject/roadmap/projects/1">here</a> under the intended release.</p></li>
<li><p>Produce the document in <a class="reference external" href="http://en.wikipedia.org/wiki/Markdown">markdown</a> format with the md extension. Once ready for review, open a PR in <a class="reference external" href="https://github.com/mantidproject/documents/tree/main/Design">here</a> or a subdirectory therein. The pull request should also include the sources (and not just the images) of any diagrams you put in the document. The diagrams can be drawn with <a class="reference external" href="https://staruml.io/">staruml</a> or similar cross-platform or WEB solution.</p></li>
<li><p>Once the PR is ready for review, put a message with a link in <em>tech-qa</em> channel, inviting the gatekeepers or other interested parties take a look and provide comments within one calendar week. Unlike the PR for code, the design reviews can and should have more than one assigned reviewer. The period can be extended if the scope is very large.</p></li>
<li><p>Answer the comments under the PR and iterate as long as needed.</p></li>
<li><p>Once the comments are incorporated, in absence of outstanding conflicts, the gatekeepers will approve and merge the PR of the design, which gives a green light to start the implementation.</p></li>
<li><p>If there is still a debate between gatekeepers, the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> will set up a dedicated meeting, where the author will be invited to present and defend the design, and all the conflicts must be settled ideally via consensus, or in the absence thereof, via majority vote.</p></li>
<li><p>Once the implementation PR is opened, the design document must be referenced in the PR message. If the feature required a design document, high is the chance that the implementation PR will require also a developer documentation.</p></li>
</ol>
</section>
<section id="design-document-content">
<h2>Design document content<a class="headerlink" href="#design-document-content" title="Link to this heading">#</a></h2>
<p>We want to avoid a prescriptive approach to design document layout.
Design documents are about communicating design ideas, not a box ticking
exercise, so developers are expected to use their own professional
judgement about what goes into them. We are not providing templates for
this reason. The following are suggestions for sections that one should normally have in a design
document:</p>
<section id="motivation">
<h3>Motivation<a class="headerlink" href="#motivation" title="Link to this heading">#</a></h3>
<ul class="simple">
<li><p>Why does this design document exist?</p></li>
<li><p>What is the overview of the problem?</p></li>
<li><p>What use cases exist showing the present issue?</p></li>
<li><p>How does this solve the requirements?</p></li>
<li><p>Note that, <em>this section should be readable to non-developers</em>.</p></li>
</ul>
</section>
<section id="dictionary-of-terms">
<h3>Dictionary of Terms<a class="headerlink" href="#dictionary-of-terms" title="Link to this heading">#</a></h3>
<p>Your opportunity to pair abbreviations to longer explanations. This is
not always necessary in documents where there are no special terms to
explain. If you need one, a two column table would be sufficient.</p>
</section>
<section id="potential-solutions">
<h3>Potential Solutions<a class="headerlink" href="#potential-solutions" title="Link to this heading">#</a></h3>
<p>It is important that you consider a wide range of possible solutions,
and don’t just put forward your favourite. Remember that the design
document is a way of avoiding mistakes before coding, so spend some time
considering how several possibilities could be made to work.</p>
<p>For each potential solution, you should probably consider:</p>
<ul class="simple">
<li><p>Keep it brief and high-level at this stage</p></li>
<li><p>What would the scope of the changes be?</p></li>
<li><p>What are the pros/cons of this solution?</p></li>
</ul>
</section>
<section id="chosen-solution">
<h3>Chosen Solution<a class="headerlink" href="#chosen-solution" title="Link to this heading">#</a></h3>
<p>You should provide logical reasons why you are choosing to adopt
solution A over solution B, C, D … As the project grows in size, we
may need to be able to understand in the future the reasons why certain
designs have been adopted. If you are unsure which solution would be
best, you may submit the partially complete design document to the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> for help. Design
is itself an iterative process and documents are frequently not accepted
first time around, so be prepared to make amendments, and don’t take it
personally if corrections are required.</p>
<p>Another thing to include is how can one verify the design? What are the use cases that could be used to prove the viability of the solution?</p>
</section>
<section id="implementation-detail">
<h3>Implementation Detail<a class="headerlink" href="#implementation-detail" title="Link to this heading">#</a></h3>
<p>You could merge this section here with the one above if you wish.</p>
<ul class="simple">
<li><p>Use feedback to correct and clarify.</p></li>
<li><p>Add more implementation detail. Diagrams are great, but you don’t
have to use strict UML, and use the appropriate UML diagrams
depending upon the solution. Diagrams should help you and readers to
understand the solution in a simple way, not make it more
complicated.</p></li>
<li><p>Could someone else follow the design and implement it based on the document without talking to you?
You may not be the one implementing this, and it’s even more likely that you will not be the only one maintaining it.</p></li>
</ul>
</section>
<section id="cheat-sheet-and-checklist">
<h3>Cheat Sheet and Checklist<a class="headerlink" href="#cheat-sheet-and-checklist" title="Link to this heading">#</a></h3>
<p>The guidelines above do not need to be strictly followed, but the following are necessary:</p>
<ol class="arabic simple">
<li><p>Can non-experts understand the motivation for these changes?</p></li>
<li><p>Does your design document link from requirements through the implementation details in a traceable manner?</p></li>
<li><p>Can someone else implement this?</p></li>
<li><p>What use cases verify that this design works?</p></li>
<li><p>Has the <a class="reference internal" href="TSC.html#tsc"><span class="std std-ref">Technical Steering Committee</span></a> approved it?</p></li>
</ol>
</section>
</section>
</section>
</article>
<footer class="prev-next-footer d-print-none">
<div class="prev-next-area">
<a class="left-prev"
href="TSC.html"
title="previous page">
<i class="fa-solid fa-angle-left"></i>
<div class="prev-next-info">
<p class="prev-next-subtitle">previous</p>
<p class="prev-next-title">Technical Steering Committee</p>
</div>
</a>
<a class="right-next"
href="CodeCoverage.html"
title="next page">
<div class="prev-next-info">
<p class="prev-next-subtitle">next</p>
<p class="prev-next-title">Generating code coverage</p>
</div>
<i class="fa-solid fa-angle-right"></i>
</a>
</div>
</footer>
</div>
<dialog id="pst-secondary-sidebar-modal"></dialog>
<div id="pst-secondary-sidebar" class="bd-sidebar-secondary bd-toc"><div class="sidebar-secondary-items sidebar-secondary__inner">
<div class="sidebar-secondary-item">
<div
id="pst-page-navigation-heading-2"
class="page-toc tocsection onthispage">
<i class="fa-solid fa-list"></i> On this page
</div>
<nav id="pst-page-toc-nav" class="page-toc" aria-labelledby="pst-page-navigation-heading-2">
<ul class="pst-show_toc_level nav section-nav flex-column">
<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#when-to-write-a-design-document">When to write a design document</a><ul class="nav section-nav flex-column">
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#amount-of-classes">Amount of classes</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#amount-of-files">Amount of files</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#abstractness-fraction">Abstractness fraction</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#the-layer-of-intent">The layer of intent</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#number-of-developers">Number of developers</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#number-of-users">Number of users</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#number-of-person-months">Number of person-months</a></li>
</ul>
</li>
<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#design-document-process">Design document process</a></li>
<li class="toc-h2 nav-item toc-entry"><a class="reference internal nav-link" href="#design-document-content">Design document content</a><ul class="nav section-nav flex-column">
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#motivation">Motivation</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#dictionary-of-terms">Dictionary of Terms</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#potential-solutions">Potential Solutions</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#chosen-solution">Chosen Solution</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#implementation-detail">Implementation Detail</a></li>
<li class="toc-h3 nav-item toc-entry"><a class="reference internal nav-link" href="#cheat-sheet-and-checklist">Cheat Sheet and Checklist</a></li>
</ul>
</li>
</ul>
</nav></div>
<div class="sidebar-secondary-item">
<div class="tocsection sourcelink">
<a href="_sources/DesignDocumentGuides.rst.txt">
<i class="fa-solid fa-file-lines"></i> Show Source
</a>
</div>
</div>
</div></div>
</div>
<footer class="bd-footer-content">
</footer>
</main>
</div>
</div>
<!-- Scripts loaded after <body> so the DOM is not blocked -->
<script defer src="_static/scripts/bootstrap.js?digest=a95f357e85573c9b56d5"></script>
<script defer src="_static/scripts/pydata-sphinx-theme.js?digest=a95f357e85573c9b56d5"></script>
<footer class="bd-footer">
<div class="bd-footer__inner bd-page-width">
<div class="footer-items__start">
<div class="footer-item">
<p class="copyright">
© Copyright 2007-2026, Mantid.
<br/>
</p>
</div>
<div class="footer-item">
<p class="sphinx-version">
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 9.1.0.
<br/>
</p>
</div>
</div>
<div class="footer-items__end">
<div class="footer-item">
<p class="theme-version">
<!-- # L10n: Setting the PST URL as an argument as this does not need to be localized -->
Built with the <a href="https://pydata-sphinx-theme.readthedocs.io/en/stable/index.html">PyData Sphinx Theme</a> 0.19.0.
</p></div>
</div>
</div>
</footer>
</body>
</html>