It claims assertions are evidence-based - does this mean all evidence is linked to - or just that the evidence is out there somewhere
Introduction
Found it a bit confusing - Communities of Practice (CoP) are defined, then an ‘analogy’ is made to Communities of Effort.
Then two examples of Communities of Effort (CoE) are made (Mozilla & Coral reefs).
No examples of Communities of Practice are given - and it’s not clear what the authors are implying about the relationship between CoPs and CoEs - e.g. are the different name for the same thing - or are CoE a sub-class of CoPs - or something else.
Rule 1
References are provided - but where is the evidence that Rule 1 works - I don’t see a reference that says ‘Codes of Conduct help newcomers’ or the like.
Rule 2
Perhaps the Apache model would be a good one to add as it’s not the same as a BDFL and it’s quite famous in Open Source
Rule 3
The most valuable advice I have heard about helping newcomers is having a set of newcomer sized tasks available - something perhaps an old hand could do quickly but something they could guide people through that would mean the newcomer learning a lot ‘by doing’ in the process.
Rule 4
Figure 1 is a bit meaningless - not very useful - it’s not clear if (a) is showing work on project or code - and so what about commits - that’s activity (and can’t assume everyone reading knows all the bits of Git) - perhaps this is one piece of info you would use when assessing a new contributor but not the only one.
Rule 5
LPP - what a horrible term - it basically says ‘your not really contributing’ - anyway. - perhaps a none code contribution to the project would be a better term - but I know LPP is a thing.
I don’t like this Rule - the take away is - file a bug, comment in a discussion or don’t worry about reputation points - how is this LPP
There is no reference give for LPP - but there is for CoP - should really define this - this is a good reference - https://en.wikipedia.org/wiki/Legitimate_peripheral_participation - I like the way it is re-assuring 'by participating in simple and low-risk tasks that are nonetheless productive and necessary and further the goals of the community’
Rule 6-8 - no comments
Rule 9
'One special of the previous rule is so important that it deserves to be a rule on its own’ - a bit informal - re-phrase
Erm - where it the evidence for this one - it’s very anecdotal and conversational - it’s a valid title but needs to be re-written.
Rule 10
This one raises an interesting point - who are you talking to in this paper - are they they open source project leaders - if so might be worth stating in the beginning.
Again no evidence or references for this point.
Conclusion
It would be nice to have one that ties everything together into a consistent whole - e.g. perhaps talking about the order in which you are to do things and the size of project - also - something not answered is are there different types of newcomers - and are some needed more that others - and if so at which stage of a project - or if this is not the case perhaps this should be dealt with here - e.g. assert ‘all newcomers help and are welcome’ - some help is better than no help?
General Comments
I keep getting the impression that the authors have a certain size of project in mind when giving their advice.
It’s clear that a 1 person project running for a year and a 10 person project running for 5 years might want to do and need to do different things to attract newcomers.
It would be useful to say either what the target project is for the advice or some kind of advice trajectory - i.e. what to do first, second etc as the project matures - the title 'Ten Simple Rules for Helping Newcomers Become
Contributors to Open Source Projects’ has two important parts - the newcomer and the open source project.
The newcomer is dealt with as a first class object in this paper, the open source project is not. The advice trajectory linked with maturity would make it more useful and practicable for adoption by open source project - as the advice stands the newcomer wins in any situations (which is good) - but it’s easy for the open source project to think it does not apply to them - which could hamper adoption of these rules.
Evidence is often provided - but I am not sure I buy the point that all Rules are evidence based/proved - the way they are specified - perhaps this claim about evidence should be softened - i.e. there is evidence to support the recommendation - not that those specific Rules have studies behind them which is the way it reads at the moment.
Abstract
It claims assertions are evidence-based - does this mean all evidence is linked to - or just that the evidence is out there somewhere
Introduction
Found it a bit confusing - Communities of Practice (CoP) are defined, then an ‘analogy’ is made to Communities of Effort.
Then two examples of Communities of Effort (CoE) are made (Mozilla & Coral reefs).
No examples of Communities of Practice are given - and it’s not clear what the authors are implying about the relationship between CoPs and CoEs - e.g. are the different name for the same thing - or are CoE a sub-class of CoPs - or something else.
Rule 1
References are provided - but where is the evidence that Rule 1 works - I don’t see a reference that says ‘Codes of Conduct help newcomers’ or the like.
Rule 2
Perhaps the Apache model would be a good one to add as it’s not the same as a BDFL and it’s quite famous in Open Source
Rule 3
The most valuable advice I have heard about helping newcomers is having a set of newcomer sized tasks available - something perhaps an old hand could do quickly but something they could guide people through that would mean the newcomer learning a lot ‘by doing’ in the process.
Rule 4
Figure 1 is a bit meaningless - not very useful - it’s not clear if (a) is showing work on project or code - and so what about commits - that’s activity (and can’t assume everyone reading knows all the bits of Git) - perhaps this is one piece of info you would use when assessing a new contributor but not the only one.
Rule 5
LPP - what a horrible term - it basically says ‘your not really contributing’ - anyway. - perhaps a none code contribution to the project would be a better term - but I know LPP is a thing.
I don’t like this Rule - the take away is - file a bug, comment in a discussion or don’t worry about reputation points - how is this LPP
There is no reference give for LPP - but there is for CoP - should really define this - this is a good reference - https://en.wikipedia.org/wiki/Legitimate_peripheral_participation - I like the way it is re-assuring 'by participating in simple and low-risk tasks that are nonetheless productive and necessary and further the goals of the community’
Rule 6-8 - no comments
Rule 9
'One special of the previous rule is so important that it deserves to be a rule on its own’ - a bit informal - re-phrase
Erm - where it the evidence for this one - it’s very anecdotal and conversational - it’s a valid title but needs to be re-written.
Rule 10
This one raises an interesting point - who are you talking to in this paper - are they they open source project leaders - if so might be worth stating in the beginning.
Again no evidence or references for this point.
Conclusion
It would be nice to have one that ties everything together into a consistent whole - e.g. perhaps talking about the order in which you are to do things and the size of project - also - something not answered is are there different types of newcomers - and are some needed more that others - and if so at which stage of a project - or if this is not the case perhaps this should be dealt with here - e.g. assert ‘all newcomers help and are welcome’ - some help is better than no help?
General Comments
I keep getting the impression that the authors have a certain size of project in mind when giving their advice.
It’s clear that a 1 person project running for a year and a 10 person project running for 5 years might want to do and need to do different things to attract newcomers.
It would be useful to say either what the target project is for the advice or some kind of advice trajectory - i.e. what to do first, second etc as the project matures - the title 'Ten Simple Rules for Helping Newcomers Become Contributors to Open Source Projects’ has two important parts - the newcomer and the open source project.
The newcomer is dealt with as a first class object in this paper, the open source project is not. The advice trajectory linked with maturity would make it more useful and practicable for adoption by open source project - as the advice stands the newcomer wins in any situations (which is good) - but it’s easy for the open source project to think it does not apply to them - which could hamper adoption of these rules.
Evidence is often provided - but I am not sure I buy the point that all Rules are evidence based/proved - the way they are specified - perhaps this claim about evidence should be softened - i.e. there is evidence to support the recommendation - not that those specific Rules have studies behind them which is the way it reads at the moment.