[Mathilde]: little detail, but do we need the practise at the end of these scripts? It is litteraly going to be the case for any script they produce so it feels redundant.

[Mathilde]: Maybe remove the markdown syntax from the hover, as they will not know what ** means. (this is a general comments, for all hovers).

[Mathilde]: I would put the bold emphasis on the first part "selecting particular variables of interest", and maybe simplifying the start of the second sentence to "Beyong that" to avoid the repetition that sounds a bit heavy and still keep the mirror of variables vs observations, which is nice.

[Mathilde]: I do not think it is more complex, nor that we should stress them by saying that. maybe keeps it for when we have several conditions?

[Mathilde]: I find it comical that this is easy when != was complex :D. I would say that the condition is more complex, but fortunately the code is still easy.

[Mathilde]: Should we allow a special case after it for the is.na()? It sort of fits there, and we can tell we will use it in the enxt session? At least the table is a bit more complete?

[Mathilde]: Make it bold like in the other examples above.

[Mathilde]: the "this is where" and "is here" feel redundant. Rephrase sightly?

[Mathilde]: go to next line to avoid very long conditions lines that needs to be scrolled right?

[Mathilde]: this part is complicated, I think because it describes an example that we don't see yet (and the text description is long and hard to understand) with general information. I advise to move the code example way higher, so that we have the real exemple in front of us before attempting to dissect it with text, not two paragraphs after.

[Mathilde]: I don't think this is very usefull, just copy and pasting the code, especially with that edgy formulation. Maybe ask them an alternative column on MUAC. Aren't there protocol modifications where MSF uses 120 mm? Cannot remember exactly. But that would allow to keep the code very similar, but the exercice a bit more complex than just copy and pasting.

[Mathilde]: Ok, I understand that both italicised and non italiscised are accepted; that removing the comas is pretty informal but growing in use (you may consider that most non native speakers might have encountered in formal text, and may find it harder to parse without the italics or the comas). But I think the : is weird.

[Mathilde]: I would move it before their exercice, when we dissect the example.

[Mathilde]: Is it really a look box? They need to code.

[Mathilde]: Should we have a tip afterwards that say that in some cases, if the vector is going to be used in several cleaning steps it can be saved outside of the pipe and show an exemple? It's not really necessary, but I like to remind them that they can create object and use them even in pipes.

Mathilde: ok, this might take some time if they try to redo it all, and they should have done something similar many times (first atr lenght with Elisabeth, then with summary in session 2, then at the sart of session 3). So maybe "look at your notes about categorical variables, whuch of them need standardizing. Hint, if you did not remember you can use count" or something like that?

[Mathilde]: Just so you know, on my screen the background of the inline code is not very distinguishable from the white backgroud of the page. I don't think I have special settings for colours during the day, so it may be a problem on other screens as well. Maybe make is slightly darker?

[Mathilde]: bit too much that one ;)

[Mathilde]: completely redundant with the following sentence. Remove?

[Mathilde]: file type?

[Mathilde]: lots of punctuation and quotes going on. Consider updating to: and testing if the value of hospitalisation equals to "yes" in this row.

[Mathilde]: Maybe precise that it's ok to have both commands, to have a dataset ready to be imported in R and one to share with colleagues who do not use R and need to be able to open a dataset in Excel or other softwares.

[Mathilde]: I am not sure about key words anymore. I feel either they are too precise to be usefull (my problem on session one and two), or too general (here?). I can't really imagine myself looking for something and these keywords being near enough to be usefull in this session for exemple.

[Mathilde]: This is conceptually an exercice for last session, but because you use the unclean variables in this session we cannot do it before: harmonise "Yes" vs "yes" etc. in all columns where this is pertinent.

[Mathilde]: deending on whether you think of bricks of needed stuff, or more general concepts (cleaning, recoding...), this might be true or not for them. Maybe rephrase to insist that they will be usefull thoughout today session?

[Mathilde]: In the previous session we used underscores in script name. I think we should we use them here as well for the sake of homogeneity in their folder. We can make a note somewhere that - are appropriate too, but it is good to be consistent within a folder.

[Mathilde]: the link does not work for now. I thought it should since it references an existing page, but maybe I am misunderstanding something?. The culprit is a "blob" in the middle: this adress works: https://github.com/epicentre-msf/repicentre/blob/main/data/raw/moissala_linelist_EN.xlsx

[Mathilde]: should we put this one in the curly braces? I agree that there is the concept of the collection of package, and the actual bundle packages, but do we want to get into this here? We told theme we would use a convention, so unless we explain them why we break it here, I would stick to it.

[Mathilde]: should we have a tooltip saying that it is due to non standard evaluation, and that the details are out of the scope of this lesson. I feel it is referenced much more often now than in the past in the documentation and online, so maybe it would be good that they have the key word somewhere?

[Mathilde]: I would print the head of this so that they see directly what it does.

[Mathilde]: Sophie had pointed in session 1 that it was "data frame" with a space. I have no idea why we wrote it otherwise in the past, but I checked the help, and I think she is right. I made the change to session 1, session 2, session 7. I'll make the change to this one as well directly in the code, just explaingin why here.

[Mathilde]: I like that we show it.

[Mathilde]: I would argue that for the French translation we should use another name (temp maybe, I don't think it is reserved in R). I feel that the most complicated english names to parse as a french are the ones where the vowells were removed. We don't do it so much as shortcuting and it's hard to figure out what the remainning letters mean. Even now, I need to read it 2 or 3 times before my brain stops reading it "te - em - pe" and understand it's a shortcuf for "temporary".

[Mathilde]: because the tooltip does not render Markdown well, I'd suggest removint the backticks around function names in them, so as to not confused them since they never see that syntax in the rest of the text.

[Mathilde]: Maybe a nice extra exercice would be to get them to use the round function, first showing them how to use it outside of mutate, and then getting them to update their mutate code to add rounding.

[Mathilde]: I feel around here is a right moment to remind them, either in a tooltip or a note below, that because we import the data in R and create new objects, at no point modifyng df_raw modifies our raw data in the data subfolder.

[Mathilde]: maybe select more of the text as the tooltip anchor, because it is not obvious to readers that there is anything to read here. (same for ymd just after, and each time we use a tooltip just on the package name)

[Mathilde]: Make it explicit that it use to obtain the desired for year-month-date format.

[Mathilde]: decide to use "date" or "Date" for the format name.

[Mathilde]: consider adding "at least in the case of fully duplicated lines" to this sentence or as a tooltip. Even with the next paragraph, I want them to realise there that two lines, identical for 32 variables, and with a typo difference in ONE variable are not going to be removed.

[Mathilde]: this sounds a bit weird. There was nothing sneaky about spending one hour and half doing it^^ Maybe it's just a bit too much and needs reformulating.

[Mathilde]: Nice explanation of the pipe you did here.

[Mathilde]: same remark as before.

[Mathilde]: I am a bit confused as to when it is grammatically correct to say "duplicate observations or entries" instead of "duplicated observations". I always use the later, and I am always a bit surprised when you use the former (in the objectives, or in the dedicated paragraph).

[Mathilde]: this sounds like a mix between "reproducibility" and "replicability". Are you sure it exists? I would have said reproducibility here.

[Mathilde]: is nrow() a function they will review in the mini exploration activity? If not, I may add a hint that we saw such a function in the past, because it was a small one we did not use much, so easy to forget (and I would not use it in a reviewing demo to refresh them on R, too small).

didn't you already do this earlier ?

i wouldn't give them the code for the solution... but i think it can be nice to show the output !

consistency issue between british and us spelling throughout doc

it's hard to tell if they are supposed to be building up a pipe or just do one offs

i don't know that i would show this in full pipe, it may be hard for them to see what you're talking about esp since its not added at the end. maybe just show the specific example you are trying to illustrate ?

alignment

by site ? is this the same pipe or a new one on the raw df ?

unclear why this is done outside the summarize

i probably wouldn't put the answers to exercises in these examples. exercises should be separate so that they have to practice

alighnment issue (either all lined up with ( or all tabbed once from the left)

i'm not sure what this means

i think this is low yeild, but up to you. if you want to keep it, you should make it one of the callouts (for example "tip").

you should put different conditions on different lines

unclear what you are asking them to do here

i'm not sure what you mean by this... are you trying to check if they know what cfr is ?

i think we decided to use the native pipe (|>); this should be updated throughout

[cat] comment here

[cat] comment example

[cat] too specific. recommend: - core - rstudio - data importation

[cat] i don't know that this linking is necessary and it adds a breakable dependency.

[cat] i would remove all internal linking. they numbers are confusing since they don't appear in the document.

[cat] this should be in english

[hugo] I still feel strongly about this. I think we should stick to simple, conventional importing with .csv and move the .xlsx import/export into it's own dedicated satellite - happy to hear what people think here. I agree the current session is not so long so .xlsx would fit in there but it's more for organisation purpose. especially because we will probably have a satellite regarding satellites, there are a lot to be said so better not duplicate.

[hugo] I would suggest we remove the object here for the variable name. I hear that it makes them practice object, but I feel it's confusing to introduce here("data", "raw") and then suddenly ask them to do here(path_data_raw, "msf_linelist_moissala_2023-09-24.xlsx"). The variable does not add much here and is only truly important with long automated scripts ...

[hugo] I would remove this, it's quite advance and such piles on the already huge load of new information they are getting here

[cat] i would put this somewhere else, either in text of the setup instruction next to it or as an important callout

[hugo] I think side notes are distracting, I have not even noticed them until now. I would suggest we move this type of information (definitions/deeper concept) to the tooltips