OpenLLM-France/wikimedia huggingface dataset:
# Software Design/Cognitive load

Cognitive load is defined by John Ousterhout in A Philosophy of Software Design as a symptom of complexity which refers to how much a developer needs to know in order to complete a task.
In a more general sense used in the Software Design project, cognitive load is the effect of a developer expending more mental efforts while working on a codebase (and, by extension, on individual tasks), either because they need to
* Learn a lot of details
* Manipulate many intertwined objects or concepts in their minds (which requires disproportionally more mental energy than keeping in mind the same number of independent objects) [citation needed]
* Sustain their focus on the tasks at hand in the face of distractions imposed by the workflow (which may be in part determined by the code itself, e. g. see quality How much navigation is needed while working with code) or by the code itself, e. g. inconsistent style
* Etc.
As a high-level code, interface, or software quality, cognitive load may be defined as the expected amount of cognitive load which will be imposed on developers of the code or the users of the interface or the software during their work with the corresponding code, interface, or software.

## Relations to qualities

Steepness of learning curve contributes to cognitive load: these qualities are both proxies of the amount of information that developers or readers need to learn in order to work with or just understand the code.

## Relevant practices

* Link to a ticket from an unusual place in code
* Object access chains: both hiding and exposing them may reduce the cognitive load of working with the code, depending on the context.
# Software Design/Compatibility

Compatibility is an external software quality. Compatibility may mean, depending on the type of the software,
* Backward compatibility, including bug compatibility and performance compatibility.
* Forward compatibility.
* Interoperability, including the ability of two versions of software to coexist in a single distributed system where individual components could be upgraded and rolled back independently.

## Relations to other software qualities

Among internal qualities, compatibility requirements mainly affect the easiness of change or the very ability to change the software in certain ways. For example, highly compatible software should keep support for older storage and wire formats and protocols for several versions to make possible unconstrained upgrade and rollback between versions. APIs (and even promises made in their specifications) of highly visible libraries such as SDKs of programming languages can never be revoked.
Among external (that is, software and interface) qualities, good compatibility may enhance the system's reliability: for example, an accidental rollout of a new software version or unintended input of data in the old format may not break the software if the backward and forward compatibility are in place. Interoperability makes easier and safer to upgrade a distributed system without downtime if every (micro)service can be upgraded separately.

## Relevant practices

* Don't use get- prefix in the name of an expensive function
* Document function's algorithmic complexity
* Specify interface contracts
# Software Design/Create pure functions

Checklist questions:
* Can the function be pure?
* Can the function be idempotent?

## Why

It's harder to make programming mistakes calling pure functions than impure functions:
* The order in which a pure function is called with respect to other functions (pure or impure) doesn't matter, therefore, calling a pure function "not in the right moment" can't be a mistake.
* A pure function doesn't access any shared state, so there can't be any race conditions due to calling a pure function concurrently with some other function modifying the same state.
* Accidentally calling a pure function multiple times can't disrupt the state of the system. Therefore, this situation should not be even considered a bug, but merely an inefficiency. This property of pure (and idempotent) functions may be seen as reliability.
Pure functions are easier to test because they don't require setting up any state. Functions mutating global state may be impossible to test in parallel which allows completing the whole test suite faster and, therefore, a shorter development feedback cycle.

## Why not

Pure functions have more parameters than equivalent impure functions, therefore calls to pure functions may look more cumbersome. There is also a risk of passing wrong arguments.
Conversion of impure functions into pure usually also requires using immutable data structures and, in general, the data organization that implies less mutability and more copying. This may increase the memory usage of the system.

## Related

* Minimize mutability
* Separate description of effectiful system from interpretation
# Software Design/Document function's algorithmic complexity

Checklist items:
* Algorithmic complexity is documented for a function (command, remote API endpoint)?
* Important performance implications (disk I/O, database queries, etc.) are documented for a function?

## Why

Specifying function's algorithmic complexity allows users to reason about their uses of the function and avoid creating too complex algorithms (such as when the function has complexity O(N) and is called from an inner loop in some code). Users may decide to cache the result(s) of an expensive function. On the other hand, caching would be deemed unnecessary if the function was cheap (had O(1) complexity).
Apart from algorithmic complexity, there are other types of performance implications of a function call which may better be documented:
* Disk IO: reading or writing.
* Database queries (and their complexity).
* RPC calls.
It's especially important to document the non-trivial complexity of functions that developers usually expect to be cheap, such as size of a collection.
Complexity and performance implications may need to be documented for classes that implement a command, or an action to be executed, as well as for remote API endpoints (such as REST API).

## Why not

* Complexity shouldn't be documented for operations that are not be expected to be executed in performance-demanding contexts.
* In general, performance may not be an important property of the software being developed.
* When the complexity of operation matches the expectations of users: for example, the complexity of functions whose names start with get- being O(1), or the complexity of a function like sum(collection) being O(N), documenting the complexity may be superfluous.
These points make, in fact, documenting algorithmic complexity and performance implications of a function a rarely applicable practice in most projects.
Documenting the algorithmic complexity of an operation and the information such as that an operation performs database queries means exposing the implementation details in the API which is an antipattern itself because it imposes compatibility constraints which might make the code harder to change in the future. This might be especially limiting when low complexity is documented, that is, that a function is cheap.

## Related Practices

* Don't use get- prefix in the name of an expensive function
# Software Design/Complexity (primary quality)

Complexity is a software, interface, and code quality characterizing the number of different states and the number and the non-regularity of interactions (relations, transitions) between the states of the software (states of the abstraction behind the interface, elements of code). This notion corresponds to Wikipedia's definition of programming complexity.
Alternatively, according to Rich Hickey, complexity (or, framed in the opposite direction, simplicity) is the quality characterized by intertwining of multiple roles, tasks, concepts, dimensions, or concerns in one entity (such as code construct, interface, or software).

## Difference with the definition from A Philosophy of Software Design

The definition of complexity used in the Software Design project differs from the John Ousterhout's definition from A Philosophy of Software Design: "complexity is anything related to the structure of a software system that makes it hard to understand and modify the system." In other words, the Software Design project's complexity is a primary quality, whereas Ousterhout's complexity is a high-level quality derived from the Software Design project's complexity, but also from many other primary qualities:
* Traceability of behavior
* Interface size and its conceptual weight
* Naturality
* Structuredness
* Apparency of semantics
* Change amplification
* Code clarity
* Code size
* How much navigation is needed while working with code
* Etc.
See Software Design § Primary vs. high-level qualities.

## Relevant practices

* Hide an object access chain
* Share state by communicating
# Software Design/Debuggability
## Relevant practices

* Hide an object access chain
# Software Design/Create "deep" functions

Checklist questions:
This practice corresponds to the principle "Modules should be deep" from A Philosophy of Software Design.

## Why

When the logic is broken up in many small functions it ends up being arranged (across the boundaries of functions' bodies) not in the execution order but in some unnatural order. This, along with the need to jump between function calls and definitions makes it more difficult for readers to understand the overall logic.
Jumping between small function bodies and calls back and forth makes developers of the code to frequently lose the visual and semantic context. They have to keep more things in mind which is an extra cognitive load. With the frequent context loss, it may also be easier to make mistakes while developing such code.
Having defined many functions which are parameterless or have the same parameters makes it easier to make a programming mistake by calling a wrong function.
When some logic is split into many functions it takes more lines of code than when the same logic is organized in a single or a few functions.
# Software Design/Discoverability

Discoverability is a code, interface, and software quality. Code discoverability characterizes how easy or hard it is for a developer to find the functionality already existing in the codebase or entities related to or dependent on some other entity, for example:
* Endpoints exposed by a server system.
* Code using a certain variable, function, or class.
* Classes implementing a certain abstract class.
Interface (API) discoverability characterizes how easy or hard it is for a user of the interface to find relevant functionality.
Code and interface discoverability is not a pure software design concern. It also depends on the tools which are used to browse and edit the software. For example, the usage of wildcard import statements (available in most programming languages), as well as static imports in languages such as Java doesn't make it harder to find usage of a variable or a function from an IDE, but may complicate this kind of discoverability when the codebase is browsed from command line or a plain-text editor.

## Examples

SPI artchitecture of an application with modules possibly defined in different codebases and assembled in runtime or on the configuration level might make hard to discover API endpoints of a service (software discoverability) unless the web framework provides a discovery/documentation page at some conventional path, such as /docs.
In object-oriented programming languages, the dot notation for calling functions (like object.doSomething) aids API discoverability because IDEs could suggest the developer functions which could be called with the given object as the reciever.
On the other hand, the fact that most of the logic written in functional programming languages is decomposed into pure functions makes search by function's type signature an effective way to discover library functionality. This is implemented in services like Hoogle for Haskell and FSDN for F#.

## Relations to other qualities

Consistent naming aids API discoverability because users could assume how functions or REST API endpoints with certain functionality may or may not be called. Structuredness may also allow users to guess with confidence in which module (class, API domain, etc.) the sought-for functionality is located.

## Relevant practices

* Hide an object access chain
* Link to related functions in the documentation for a function
* Build an object-based API
* Make RPC calls discoverable in code
# Software Design/Complexity (high-level quality)

Complexity as a high-level code quality is defined by John Ousterhout in A Philosopy of Software Design as "anything related to the structure of a software system that makes it hard to understand and modify the system." It is derived from the following qualities:
* Complexity as a primary quality
* Steepness of learning curve
* Interface size and its conceptual weight
* Naturality
* Code clarity
* Code size
* Easiness of change
* And other qualities.
# TAO/Stakeholder groups

To do: Identify the various stakeholder groups of our learning and research project; identify strategies to include them in the project

## Overview of Stakeholder Groups

| Stakeholder group | Priority for inclusion (1-5) | Timeline | Strategy for inclusion | Comments |
| Members of the TAO research team | 1 | 2011/Q4 | Start from existing research activities; produce input for the handbook based on insights from TAO research activities | ongoing |
| Representatives of TAO community partners | 1 | 2011/Q4 | Start from existing pilot projects that enter the multiplication phase; produce input for the handbook based on insights derived from practical experiences | ongoing |
| Example | Example | Example | Example | Example |

## Further groups to be included

Brainstorming... (please add further ideas)
* Volunteers from the different community partner organizations (Seniorweb CH, Seniorweb NL, Wikimedia CH, Wikimedia DE) involved in the project TAO
* Wikimedians from other countries who have experience with integrating older people
* Representatives from other Wikimedia chapters interested in running outreach activities targeted at 50plus
* Members of the TAO Evaluation & Advisory Board (list to be published on the TAO website)
* Partners from the "Seniors in the Knowledge Society" project (Universities of the Third Age, Seniorweb-like organizations, etc.) who are interested in setting up learning communities and communities of practice for 50plus
* Further Seniors-Communities (Seniorennet Belgium, Seniorweb Sweden, England: Ageing Well, Norway, Feierabend...)
** Virtuelles und reales Lern- und Kompetenznetzwerk älterer Erwachsener (ViLE) e.V.
** Netzwerk der Senioren-Internet-Initiativen in Baden-Württemberg
** seniorbook (Germany)
* Universities of the Third Age
** Schweizerische Vereinigung der Seniorenuniversitäten
** Bundesarbeitsgemeinschaft Wissenschaftliche Weiterbildung Älterer (BAG WiWA)
* Volkshochschulen / Universités populaires
** Verband der Schweizerischen Volkshochschulen
** Volkshochschulen in der Schweiz
** Migros Klubschule
* Seniors Interest Organizations
** Schweizerischer Seniorenrat / Conseil suisse des aînés
** Bundesarbeitsgemeinschaft der Seniorenorganisationen in Deutschland (BAGSO)
* NGOs promoting e-inclusion among older people
** Stiftung Digitale Chancen
** Mondo Digitale (Italy) with the Learning Partnership Knowledge Volonteers
# TAO/Silver Surfers' Social Services

* Preliminary Study 60Plus
* Focus Group Conversations SWNL
* First Wave TAO Survey NL - DE - CH
# TAO/Taking stock of the project TAO
## Goal of the Module

Take stock of the project TAO's outputs with view of their documentation in form of the TAO Handbook.

## Target group

Members of the project TAO.

## Step 1: Get the big picture

Take the inventory of the TAO project's (expected) outputs that are supposed to find entry to the TAO Handbook: Inventory.

## Step 3: Document existing project know-how

Guidelines for the production of handbook entries:
* The documentation of project know-how needs to be tailored to the target groups' needs and preferences (see personas as well as the problem-based approaches). In order to reach this goal, the documentation should take place in an iterative process, where some draft handbook content is produced and then shown to target group representatives in order to gather feedback.
* The handbook entries should as much as possible be evidence based. Similar referencing standards should be applied as for Wikipedia articles in order to make assertions in the handbook traceable to their source. One major difference being that results from original research are admitted; in this case publication in peer-reviewed journals should however be aimed for as well (thus producing solid references on the go).
* The handbook entries shall be complementary to corresponding Wikipedia articles; there is no point in filling the handbook with information that may as well be the object of a Wikipedia article. In this case, contact with the Wikipedia community should be sought in order to develop the Wikipedia articles in question.

## Step 4: Define research tasks to fill the gaps

Based on the problem-based approaches new research questions may be developed and tackled within the project TAO or beyond.
# TAO/Tell us about yourself

- This site is currently under development -
# Primitive function/sin (ln)/Exercise

Determine an antiderivative (primitive function) of the function
    $\sin(\ln x).$
# Primitive function/x^3 cos x - x^2 sin x/Exercise

Determine an antiderivative (primitive function) of the function
    $x^{3}\cdot \cos x-x^{2}\cdot \sin x.$
# Primitive function/x^3 over 5th root of x^4+2/Exercise

Determine an antiderivative (primitive function) of the function
    ${\frac {x^{3}}{\sqrt[{5}]{x^{4}+2}}}.$
# Primitive function/x^n ln x/Exercise

Determine an antiderivative (primitive function) of the function
    $x^{n}\cdot \ln x.$
# Primitive function/tan x/Exercise

Determine an antiderivative (primitive function) of the function
    $\tan x.$
# Primitive function/f (bt+c) with primitive functions/Exercise

Let $I$ be a real interval and let
    $f\colon I\longrightarrow \mathbb {R}$
be a continuous function with antiderivative $F$. Let $G$ be an antiderivative of $F$ and let $b,c\in \mathbb {R}$. Determine an antiderivative of the function
    $(bt+c)\cdot f(t).$
# Primitive function/ln (1+sin) sin/Exercise

Determine an antiderivative (primitive function) of the function
    $(\ln(1+\sin x))\cdot \sin x.$
# Primitive function/sin^2 over cos^2/Exercise

Determine an antiderivative (primitive function) of the function
    ${\frac {\sin ^{2}x}{\cos ^{2}x}}.$
# Primitive function/x^2 over (x cos x -sin x)^2/Example

We want to find a primitive function for the function
    $f(x)={\frac {x^{2}}{(x\cos x-\sin x)^{2}}}\,.$
We first determine the derivative of
    ${\frac {1}{x\cos x-\sin x}}.$
This is
    $-{\frac {\cos x-x\sin x-\cos x}{(x\cos x-\sin x)^{2}}}={\frac {x\sin x}{(x\cos x-\sin x)^{2}}}\,.$
Therefore, we write $f$ as a product $f(x)={\frac {x\sin x}{(x\cos x-\sin x)^{2}}}\cdot {\frac {x}{\sin x}}$. We apply integration by parts, where we integrate the first factor and differentiate the second factor. The derivative of the second factor is
    ${\left({\frac {x}{\sin x}}\right)}'={\frac {\sin x-x\cos x}{\sin ^{2}x}}\,.$
Hence, we have
    ${\begin{aligned}\int _^f(x)\,dx&={\frac {1}{x\cos x-\sin x}}\cdot {\frac {x}{\sin x}}-\int _^{\frac {1}{x\cos x-\sin x}}\cdot {\frac {\sin x-x\cos x}{\sin ^{2}x}}\,dx\\&={\frac {1}{x\cos x-\sin x}}\cdot {\frac {x}{\sin x}}+\int _^{\frac {1}{\sin ^{2}x}}\,dx\\&={\frac {1}{x\cos x-\sin x}}\cdot {\frac {x}{\sin x}}-\cot x.\end{aligned}}$
# Primitive function and Riemann-Integral/1 over x sin 1 over x^2/Example

We consider the function
    $f\colon \mathbb {R} \longrightarrow \mathbb {R} ,t\longmapsto f(t),$
given by
    $f(t):={\begin{cases}0{\text{ for }}t=0,\\{\frac {1}{t}}\sin {\frac {1}{t^{2}}}{\text{ for }}t\neq 0\,.\end{cases}}\,$
This function is not Riemann-integrable, because it it neither bounded from above nor from below. Hence, there exist no upper step functions for $f$. However, $f$ still has a primitive function. To see this, we consider the function
    $H(t):={\begin{cases}0{\text{ for }}t=0,\\{\frac {t^{2}}{2}}\cos {\frac {1}{t^{2}}}{\text{ for }}t\neq 0\,.\end{cases}}\,$
This function is differentiable. For $t\neq 0$, the derivative is
    $H'(t)=t\cos {\frac {1}{t^{2}}}+{\frac {1}{t}}\sin {\frac {1}{t^{2}}}\,.$
For $t=0$, the difference quotient is
    ${\frac {{\frac {h^{2}}{2}}\cos {\frac {1}{h^{2}}}}{h}}={\frac {h}{2}}\cos {\frac {1}{h^{2}}}\,.$
For $h\mapsto 0$, the limit exists and equals $0$, so that $H$ is differentiable everywhere (but not continuously differentiable). The first summand in $H'$ is continuous, and therefore, due to fact, it has a primitive function $G$. Hence $H-G$ is a primitive function for $f$. This follows for $t\neq 0$ from the explicit derivative and for $t=0$ from
    $H'(0)-G'(0)=0-0=0\,.$
# System development/Domains/Overview/Finance/Processes/Opening an account

The following stages and steps can be defined when opening an account.
* Collect accountholder information
** Complete Application
** Verify Mailing Address
* Open Account
** Check Credit Report
** Background check
* Fund Account
** Collect Bank Info
** Initiate Debit (Subcase)
** Request Check (Subcase)
* Resolve Request
** Subscribe to NewsLetter
** Assign Broker (Subcase)
** Enroll in GloboBank U (Subcase) Cuba and the Caribbean working group
# System development/Domains/Overview/HCM

HCM stands for Human Capital Management.

## Index

* Best practices
* Business objectives
* Case studies
* eHRM
* Ontology
* Processes: See Subdomains
* Software
* Subdomains
* To-do
* Vision
# System development/Domains/Overview/HCM/Ontology
## Concepts

* Employee
* Job
* Organization
* Position
# System development/Domains/Overview/HCM/Software

On this page you can find information about HCM software.

## Recent development

According to this blogpost of Helder Silva companies should choose for Workday.

## Index

* SuccessFactors
* Workday
# System development/Domains/Overview/HCM/Subdomains

On this page you can find an overview of HCM subdomains.
* Absence
* Career management
* Compensation and Benefits
* Expenses
* Employee Relations
* Employee Remuneration and Benefits Administration
* Goal setting: see Performance management
* Hiring
* HR controlling
* Leadership development
* Leave
* Onboarding
* Organizational management
* Performance management
* Recruitment
* Selection
* Succession
* Talent management
* Termination
* Training and development
# System development/Domains/Overview/Finance

Finance is a field that deals with the allocation of assets and liabilities over time under conditions of certainty and uncertainty.

## Index

* Best practices
* Case studies
* Ontology
* Processes
* Software
* Subdomains
* To-do
* Vision
# System development/Domains/Overview/Finance/Ontology

On this page you can find an ontology for the finance domain.

## Concepts

| Concept | Dutch |
| Account | Rekening |
| Account holder | Rekeninghouder |
| Balance | Saldo |
| Pay Request | Betalingsverzoek |