Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest changes to SE skills section #231

Merged
merged 14 commits into from
Apr 5, 2024
Merged

Suggest changes to SE skills section #231

Changes from 4 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
f70503c
Suggest changes to SE skills section
Jan 23, 2024
e7b43d0
Update competencies.md
CaptainSifff Jan 25, 2024
6fec2ef
Apply suggestions from code review
CaptainSifff Mar 26, 2024
d061e00
Merge branch 'main' into patch-3
CaptainSifff Mar 26, 2024
8a16e8e
Update competencies.md
CaptainSifff Mar 26, 2024
8132017
Apply suggestions from code review
CaptainSifff Mar 26, 2024
73b045a
Update competencies.md with @sdruskat's suggestion in order to work o…
CaptainSifff Mar 26, 2024
a0ef74f
Update competencies.md
CaptainSifff Mar 26, 2024
7db5692
Apply suggestions from code review
CaptainSifff Mar 26, 2024
c4873aa
Merge branch 'main' into patch-3
CaptainSifff Mar 26, 2024
af43ecf
replaced another instance of software engineering skill
mhagdorn Mar 27, 2024
3fd4d20
make spellchecker happy
mhagdorn Mar 27, 2024
16941c7
FAIR is in glossary, FAIR4RS is reference to paper
mhagdorn Mar 27, 2024
0f58d47
do not spell check intro.md it was removed with 4b9d44
mhagdorn Mar 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 35 additions & 16 deletions competencies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -308,8 +308,8 @@

The activities of an RSE are guided by ethical values.
In addition to the values for good scientific practice [@dfg_gsp], RSEs also adhere to
the \ac{SE} Code of Ethics [@Gotterbarn1999].

Check failure on line 311 in competencies.md

View workflow job for this annotation

GitHub Actions / spellcheck

Misspelled word 

Misspelled word "develoment".
Suggested alternatives: "development", "envelopment"
If you want to ignore this message, add develoment to the ignore file at .github/spellignore.txt
Central to that code is the RSE's obligation to

Check failure on line 312 in competencies.md

View workflow job for this annotation

GitHub Actions / spellcheck

Misspelled word 

Misspelled word "iteratively".
Suggested alternatives: "alliteratively", "imperatively", "interactively", "alliterative"
If you want to ignore this message, add iteratively to the ignore file at .github/spellignore.txt
commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.
Further values loosely based on that code include the obligations

Expand Down Expand Up @@ -380,7 +380,7 @@
(the "R") and a software engineer (the "SE") and, therefore, requires
competencies in both fields. RSEs typically apply their knowledge and
experience in larger teams which allows them to cultivate this hybrid nature.
Therefore, we categorise the competencies into three categories: *software engineering skills*,
Therefore, we categorise the competencies into three categories: *software/technical skills*,
*research skills*, and *communication skills*, with a particular focus on the software and
research cycle and the scientific process. These competencies are relevant in a
broad setting and form the foundation for specific specialisations.
Expand All @@ -396,19 +396,36 @@
(**Project team size**). Finally, different sets of skills are emphasised in
the different RSE specialisations (**RSE specialisations**).

## Software engineering skills
## Software/Technical skills

\newcommand{\skillsection}[1]{\hypertarget{skills-#1}{%
\subsubsection{\glsentrydesc{#1} (\texorpdfstring{\glsentrytext{#1}}{#1})}\label{skills-#1}}}

There are many \ac{SE} curricula out there, that try to define
which tasks a software engineer should be able to perform. A recent example
highlighting some aspects in more detail than here is @Landwehr2017.
The software skills outlined here are required to make research software adhere
to the \ac{FAIR} principles, which are aspects of good scientific practice.
@ChueHong2014 defines different levels of research
software reusability and the extent to which the \ac{SE} skills
need to be applied to reach them.
The technical skills required by an RSE overlap to a large extent with the common
fundamental software engineering skills (see, e.g., @Landwehr2017), but put greater
emphasis on aspects related to achieving good scientific practice.
For example, RSEs need to know how to make research software adhere to the
\ac{FAIR4RS} principles, and how to achieve different levels of research
software reusability @ChueHong2014. To reflect this, the technical skills
listed below complement competencies regarding the standard life-cycle of
software development with RSE-specific focus skills.


<!-- Adapting to the software life-cycle -->
\skillsection{SWLC}

The traditional software development life-cycle defines the stages that form the process of building a piece of software.
Initial development generally involves an analytic process where needs and ideas are gathered and analysed (requirements engineering),
followed by a formulation of a plan to fulfil them (design) that is finally turned into running code (implementation).
This is accompanied by different measures of quality control (e.g., reviews, testing), validating and verifying
that things work as expected and that they continue to do when develoment progresses further.
Often the development cycles are executed iteratively and incrementally.
The life-cycle further includes periods of deployment, maintenance and further development (software evolution),
as well as software retirement.
Additionally, the research software life-cycle extends the traditional life-cycle
with \gls{software-publication}. The RSE should be aware of this life-cycle
and be able to predict and cater to the changing needs of a software project as it moves through the stages.
Comment on lines +426 to +427
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see, how to predict changing needs beyond the most obvious ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mschwarzmeier What exactly is your question/point here?

Copy link
Collaborator

@mschwarzmeier mschwarzmeier Feb 14, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, I fully understand this sentence. Maybe an example could help?
@annalenalamprecht

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has just been moved from a different position in the paper is not really a new addition.
So let's just keep it as is for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder to Flo: I think currently it's duplicated.



<!-- Creating documented code building blocks -->
\skillsection{DOCBB}
Expand Down Expand Up @@ -449,14 +466,15 @@
<!-- Use repositories -->
\skillsection{SWREPOS}

The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos) to share the artefacts they have
created and invite the public to scrutinise them for public review.
The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos with version control)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that the big competencies over here should be tech stack independent, and therefore we concentrated on the sharing with people and reviewing of contributions aspect of platforms like github. Due to them being manifestations of human interactions I feel they should exist even after the point in time, when the version control aspect is not visible to the average user anymore but suitably automated away. Side note: we need to introduce the word repo here, since we use it later on the tables which are less abstract.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not mentioning version control here is fine with me

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see in current main, "version control" as a skill is only mentioned in passing in Appendix A. This is widely at odds with current teaching practice, where VCS is one of the early and central (perhaps the central) skill taught to researchers (see, e.g., The Carpentries curricula, but also Helmholtz & DLR practice).

I see the point you are making @CaptainSifff, but think it'd be very odd not to mention version control here at all!

In fact, I think that the current wording is a bit too abstract to explain the use of SWREPOS in the tables further down, where, e.g., Table 1 says "Should seamlessly interact with the repository of their project.", where repository to me clearly points to a version control repo! I'll make a change suggestion to that effect.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And even thinking of the future of automation. I'd still want some form of versioning to be able
to point to the specific version I used to do my computations.
So I'd still have to somehow interact with it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh and who would be most likely to automate the version control aspect of research?
Us RSEs probably xD So we should still know how it works to be able to maintain the software.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the issue is that there is a difference between versioning and version control. The repo tracks changes, in the simplest case that is just a linear history of changes (which is sufficient for a small project). Versioning then identifies particular snapshots of the software. Different strategies for versioning exist - major.minor.micro versions, pre-releases, development releases, time based releases, etc. Actually the right term is release management. I think that is something that is missing in the paper.

to share the artefacts they have created and invite the public to scrutinise them for public review.


<!-- Software behaviour awareness and analysis -->
\skillsection{MOD}

We define this as a certain quality of analytical thinking that enables an RSE to
form a mental model of a piece of software in a specific environment.
form a mental model of a piece of software in a specific environment (program comprehension).
Using that, an RSE should be able to make predictions about a software's behaviour.
This is a required skill for common tasks such as debugging, profiling, optimising, designing good
tests, or predicting user interaction.
Expand Down Expand Up @@ -671,9 +689,9 @@

| Competency | Junior RSE | Senior RSE | Principal RSE |
| --- | ---------- | ---------- | ---------- |
| \gls{SWLC} | Should be aware of the software life-cycle. | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt. | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
| \gls{DOCBB} | Should be able to write reusable building blocks. | Same as junior, but the quality should set the standard for the project, while following current best practices. | Should know the current best practices and point their staff to the right resources. |
| \gls{LIBS} | Should be able to use package distribution platforms. | Same as junior, but should also be familiar with current best practices for building and deploying packages. | Should ensure that their project is available via an up-to-date and secure distribution platform. |
| \gls{SWLC} | Should be aware of the software life-cycle. | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt. | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
| \gls{SWREPOS} | Should seamlessly interact with the repository of their project. | Should be well-versed in the intricacies of a repository, and probably interact with repositories of multiple projects. | Should promote the use of repositories and be able to convey best practices to junior and senior RSEs. |
| \gls{MOD} | Should have a basic grasp of their piece of the software in order to use basic tools such as a debugger. | Should understand the characteristics of large parts of the codebase considering a variety of the metrics. | Should understand the big idea of the software project in order to define the task that the software solves. |

Expand Down Expand Up @@ -1175,9 +1193,9 @@

<!--
social skill-set focused specialisations
-->

Check failure on line 1196 in competencies.md

View workflow job for this annotation

GitHub Actions / spellcheck

Misspelled word 

Misspelled word "Emphasizing".
Suggested alternatives: "Emphasising"
If you want to ignore this message, add Emphasizing to the ignore file at .github/spellignore.txt

# Future work {#sec:future-work}

Check failure on line 1198 in competencies.md

View workflow job for this annotation

GitHub Actions / spellcheck

Misspelled word 

Misspelled word "emphasizing".
Suggested alternatives: "emphasising"
If you want to ignore this message, add emphasizing to the ignore file at .github/spellignore.txt

Having the competencies is a first step to finding common ground around which to structure
curricula, institutions, and teachers in this framework.
Expand Down Expand Up @@ -1283,10 +1301,11 @@

Core modules are of course drawn from the three pillars of the RSE and can be categorised accordingly.

- \ac{SE} skills:

- Software/Technical skills:
- Foundational module: Here we have an introduction to programming: Emphasizing use cases over programming paradigms, students learn at least two languages: a language that facilitates prototyping and data processing (e.g., \gls{Python} or \gls{R}) and a language for designing complex, performance-critical systems (e.g., \gls{C}/\gls{Cpp}). This exposes them to computers in a hands-on fashion and is the foundation for (\gls{DOCBB}, \gls{LIBS}).
- Computing environment module: Programming languages are not enough to work in a landscape of many interconnected software components; hence we require something like software craftsmanship, where tools such as the Unix shell, version control systems, build systems, documentation generators, package distribution platforms, and software discovery systems are taught to strengthen skills in (\gls{LIBS}, \gls{DOCBB}, \gls{SWREPOS}, \gls{SRU}).
- Software architecture module: Here we teach software design and \ac{SE}, again strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.
- Software engineering module: Here we develop foundational software engineering competencies (basic knowledge and skill regarding requirements engineering, software architecture and design, implementation, quality assurance, software evolution), practicalities of carrying out a software project (e.g., use of version control and other software development support tools), again emphasizing and strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The meaning has changed here.... The Software Development tools, we would have placed into Digital Ecosystem Module, whereas the architecture part over here, is more like the high-level view of how to grow big softwares.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can remove the "practicalities ..." part here, especially as the importance of practical projects is emphasized a little later in the paper.


- Research skills:
- Optional domain mastery module: Additional minor research courses, but students with a home-domain already have the research part well-covered.
Expand Down
Loading