Closed mhagdorn closed 1 month ago
3.5 is on technical aspects, so we can concentrate on 3.3 and 3.4
What I've taken with me, that I'd consider important and useful is to workout the engineering aspect. We could try to bring more of the traditional engineering qualities like handling of complexity and especially the reliability aspect into it. The reliability aspect could lead to a fruitful cross-over with the FAIR aspect currently going on in research.
pinging todays participants: @annalenalamprecht @mhagdorn @juckel @knarrff @jlinx @jcohen02 @michelemartone @jngrad
pinging @hvwaldow since you have a branch floating around in that direction.
3.5 is on technical aspects, so we can concentrate on 3.3 and 3.4
What I've taken with me, that I'd consider important and useful is to workout the engineering aspect. We could try to bring more of the traditional engineering qualities like handling of complexity and especially the reliability aspect into it. The reliability aspect could lead to a fruitful cross-over with the FAIR aspect currently going on in research.
3.3 scheint aber eher Material zur "Softwareklassifikation / Technology Readyness Level" und dann noch das Inhaltsverzeichnis von SWEBOK zu enthalten. Unklar, was man da berücksichtigen sollte.
I just read sections 3.3 and 3.4 and skimmed 3.5. My feeling is that we are not far away. So it might just boil down to making the links more explicit.
Maybe first list section headings of 3.4 . This Chapter is hmmm ... inhomogenous with respect to categories? There are sections that only deal with specific tools and current practices (UML-diagrams, Git) next to sections that relate to a whole module in an SE curriculum (RE, architekture, ...) As @mhagdorn says, we have already covered quite a bit of that.
I'm AFK till Monday, sorry.
So, I have read our paper and Sections 3.3-3.5 again. I note that in the Leitfaden documentation is hidden 3.4.8 and communication is not explicitly mentioned. I also note that Computing and Mathematical Foundations are glossed over. I do think they play an important role in the profile of RSEs. I think we are covering all the items of the table in 3.3.2. We are putting different emphasis and redistribute competencies. We even have part of SE Economics in the form of green computing in there. Given that I find it difficult to reconcile the different standpoints.
I do think we need to make clear that an RSE Master Programme should contain all the SE core competencies. Maybe, that would also be reflected in our Tables 1, 2 ad 3. We could add some sentences to that effect into the introduction of Section 4. I might also be helpful to mention that we redistributed some of the SE competencies onto our 3 pillars to put different emphasis.
I am not sure where the term Scientists who Code comes from. It's the first time I've heard this term. Is it established? My understanding of the term RSE is that it encompasses the entire spectrum. I think our RSE definition in 1.1 is missing the lone developers that work on code for their own research. Having said that, I think scientists who code captures what we are trying to say. So maybe we could describe RSEs to include the entire spectrum from SwC to SEs.
I really like the idea (of @hvwaldow I think) that RSE is not associative, ie (RS)E != R(SE).
Note, that you might also give the feedback on various properties of the Leitlinien Document back to them.
I am not sure where the term Scientists who Code comes from. It's the first time I've heard this term. Is it established? My understanding of the term RSE is that it encompasses the entire spectrum. I think our RSE definition in 1.1 is missing the lone developers that work on code for their own research. Having said that, I think scientists who code captures what we are trying to say. So maybe we could describe RSEs to include the entire spectrum from SwC to SEs.
I don't like the term Scientists who Code. This is very subjective, but to my ears it seems to subtly prompt ".... but shouldn't, really".
So maybe we could describe RSEs to include the entire spectrum from SEs to Scientists Who Develop Software.
I don't like the term Scientists who Code. This is very subjective, but to my ears it seems to subtly prompt ".... but shouldn't, really".
So maybe we could describe RSEs to include the entire spectrum from SEs to Scientists Who Develop Software.
yes, I can see that issue. However, that would be yet another term. So I wonder how established this term is and whether we need to contribute to its establishment (probably not) or if we can just ignore it like we have done so far.
I didn't see this as a fixed expression before. And then I can imagine that there are scientists who code which we won't consider RSEs, no?
the term does come up in various place when you do a google search. I wonder if this is really the issue, when is somebody considered an RSE and when not. Personally, I think we shouldn't be prescriptive and leave it as an open and inclusive term.
I think we shouldn't be prescriptive and leave it as an open and inclusive term
Yes. But wouldn't an expression "from X to Y", which implies 1) a direction and 2) endpoints of an interval sabotage this goal?
Yes. But wouldn't an expression "from X to Y", which implies 1) a direction and 2) endpoints of an interval sabotage this goal?
this would argue against the subtitle (something we should discuss on Monday) and for leaving Section 1.1 as is. I wonder if tend to overspecify things. I think your suggestion for subtitle does not imply a direction. I also like the symmetry of the subtitle. I'd be happy with that.
That subtitle gatherd some positive reactions and yes, it doesn't imply a direction ("and" instead of "from ... to ..."). Question is whether we need a subtitle at all ...
look into condensing and incorporating missing items from RSE Leitlinien document, sections 3.3 to 3.5.