[release] Drawing new contributors with simple tasks


Guillaume Lambert
 

Hi everyone

I completely share Robert's opinion here.
Robert, apart taking on my own some of the JIRA issues, I can try to give you a hand on guiding newcomers.
We faced these difficulties when beginning transportPCE. According to me, the 2 main problems are:
- most people do not know Gerrit (and even Git) subtleties
( they are usually familiar with Github / GitLab PR which has a different philosophy)
- and as you pointed, best practices and step-by-step guides and other materials are spread over a lot of pages
in our documentation, what fears potential contributors.
A few years ago, I tried my best to centralize the minimum material for newcomers in a page on our wiki,
now at https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines
Though not obsolete, this page is a bit outdated because of latest Gerrit evolutions.
I am currently working on it again to fill new needs, by listing some best practices for our contributors
and by simplifying openstack documentation, which is more complete than ODL on the topic in my opinion.
https://docs.openstack.org/openstack-ansible/queens/contributor/code-rules.html
https://wiki.openstack.org/wiki/GitCommitMessages
That can be good basis to start with.

Hope this helps
Guillaume

-----Message d'origine-----
De : release@... [mailto:release@...] De la part de Robert Varga
Envoyé : dimanche 18 octobre 2020 23:33
À : discuss@...; release@...; tsc@...; dev@...
Objet : [release] Drawing new contributors with simple tasks

Hello everyone,

this is yet another wall of text from me. TL;DR is: we want to give visibility of easy tasks so that even causal ODL users see where they can contribute.

If that interests you, please read on. If not and you'd like more relevant content from me, please unicast :)


We are faced with a dire lack of contributions, that is fact. We want to attract new contributors as much as possible.

Another fact is that we are being used in production environments, which sets the bar for contribution quality quite high.

This leads to competing requirements, where people willing to enter the community with a fix will be faced with dire requirements -- just because of the sensitive nature of the area they are touching.

We also lack the community resources to support on-boarding newcomers, most highlighted by our inability to grow the community via internships.

Being the top contributor (by more than a fair margin) who ends up doing all sorts of menial tasks, I think we need to start communicating the need, and receiving help with, a number of low-priority but nice-to-have-fixed issues.


One way of doing that is defining, labeling and publishing issues which we (the ODL community) know to be (relatively) easy to do, but are simply not of priority at a particular point in time.

For the definition part, I can say that filing a descriptive JIRA issue takes 5-10 minutes, where the effort required to solving it takes 4-16 hours.

For the labeling part, I took the liberty of defining a new label, 'quickwin', in JIRA. There a whooping one issue in https://jira.opendaylight.org/issues/?jql=labels%20%3D%20quickwin

What I struggle with is the question of communication -- and hence this wall of text (again, sorry, but heck there's so much context first!).

Can we perhaps create a documentation page for this?

My thinking is that it should be the first item under https://docs.opendaylight.org/en/latest/#opendaylight-contributor-guides
and would serve as the bare-bones, minimum-requirements, step-by-step HOW-TO of getting involved.

What do you think?

Regards,
Robert

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Abhijit Kumbhare
 

Guillaume,

This ( https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines) is great stuff. Is it OK to migrate it to the Contributor Info page that I created at the top level of the OpenDaylight Wiki? The page is: https://wiki.opendaylight.org/display/ODL/Contributor+Info. For now I have just created a single page for the "Best Practices" under the Contributor Info Page - all of the best practices should be ideally migrated over but for now I am just pointing to https://wiki-archive.opendaylight.org/view/BestPractices from this page. 

Thanks,
Abhijit

On Mon, Oct 19, 2020 at 5:55 AM Guillaume Lambert via lists.opendaylight.org <guillaume.lambert=orange.com@...> wrote:
Hi everyone

I completely share Robert's opinion here.
Robert, apart taking on my own some of the JIRA issues, I can try to give you a hand on guiding newcomers.
We faced these difficulties when beginning transportPCE. According to me, the 2 main problems are:
- most people do not know Gerrit  (and even Git) subtleties
  ( they are usually familiar with Github / GitLab PR which has a different philosophy)
- and as you pointed, best practices and step-by-step guides and other materials are spread over a lot of pages
   in our documentation, what fears potential contributors.
A few years ago, I tried my best to centralize the minimum material for newcomers in a page on our wiki,
now at https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines
Though not obsolete, this page is a bit outdated because of latest Gerrit evolutions.
I am currently working  on it again to fill new needs, by listing some best practices for our contributors
and by simplifying openstack documentation, which is more complete than ODL on the topic in my opinion.
https://docs.openstack.org/openstack-ansible/queens/contributor/code-rules.html
https://wiki.openstack.org/wiki/GitCommitMessages
That can be good basis to start with.

Hope this helps
Guillaume

-----Message d'origine-----
De : release@... [mailto:release@...] De la part de Robert Varga
Envoyé : dimanche 18 octobre 2020 23:33
À : discuss@...; release@...; tsc@...; dev@...
Objet : [release] Drawing new contributors with simple tasks

Hello everyone,

this is yet another wall of text from me. TL;DR is: we want to give visibility of easy tasks so that even causal ODL users see where they can contribute.

If that interests you, please read on. If not and you'd like more relevant content from me, please unicast :)


We are faced with a dire lack of contributions, that is fact. We want to attract new contributors as much as possible.

Another fact is that we are being used in production environments, which sets the bar for contribution quality quite high.

This leads to competing requirements, where people willing to enter the community with a fix will be faced with dire requirements -- just because of the sensitive nature of the area they are touching.

We also lack the community resources to support on-boarding newcomers, most highlighted by our inability to grow the community via internships.

Being the top contributor (by more than a fair margin) who ends up doing all sorts of menial tasks, I think we need to start communicating the need, and receiving help with, a number of low-priority but nice-to-have-fixed issues.


One way of doing that is defining, labeling and publishing issues which we (the ODL community) know to be (relatively) easy to do, but are simply not of priority at a particular point in time.

For the definition part, I can say that filing a descriptive JIRA issue takes 5-10 minutes, where the effort required to solving it takes 4-16 hours.

For the labeling part, I took the liberty of defining a new label, 'quickwin', in JIRA. There a whooping one issue in https://jira.opendaylight.org/issues/?jql=labels%20%3D%20quickwin

What I struggle with is the question of communication -- and hence this wall of text (again, sorry, but heck there's so much context first!).

Can we perhaps create a documentation page for this?

My thinking is that it should be the first item under https://docs.opendaylight.org/en/latest/#opendaylight-contributor-guides
and would serve as the bare-bones, minimum-requirements, step-by-step HOW-TO of getting involved.

What do you think?

Regards,
Robert

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.





Robert Varga
 

On 22/10/2020 00:15, Abhijit Kumbhare wrote:
Guillaume,

This ( https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines
<https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines>) is
great stuff. Is it OK to migrate it to the Contributor Info page that I
created at the top level of the OpenDaylight Wiki? The page
is: https://wiki.opendaylight.org/display/ODL/Contributor+Info
<https://wiki.opendaylight.org/display/ODL/Contributor+Info>. For now I
have just created a single page for the "Best Practices" under the
Contributor Info Page - all of the best practices should be ideally
migrated over but for now I am just pointing
to https://wiki-archive.opendaylight.org/view/BestPractices
<https://wiki-archive.opendaylight.org/view/BestPractices> from this page. 
Abhijit, with all due respect, let us not move from one wiki to another.
We have agreed many moons ago to keep in the docs.

Having all that content in .rst makes it more maintainable, searcheable
and actually makes it a lot more visible -- for example here:
https://github.com/opendaylight/docs/blob/master/docs/index.rst

docs.opendaylight.org is the place we are pointing everyone to, so when
we are migrating content *PLEASE* let us migrate it once and for all.

All of that before going to the point that, unlike a Wiki edits, changes
to .rsts can be properly reviewed.

Thanks,
Robert


Guillaume Lambert
 

Hi all

 

Abhijit, Robert, thank you a lot for your kind feedbacks.

 

Abhijit, I am fine with moving this at the top of the wiki
 I also agree with Robert that it would be better placed in the documentation in the more maintainable RST format.

I can give a hand on translating it to RST. I should still have an old version in Markdown somewhere…

 

BR

Guillaume

 

De : release@... [mailto:release@...] De la part de Abhijit Kumbhare
Envoyé : jeudi 22 octobre 2020 00:15
À : LAMBERT Guillaume TGI/OLN
Cc : Robert Varga; discuss@...; release@...; tsc@...; dev@...
Objet : Re: [release] Drawing new contributors with simple tasks

 

Guillaume,

 

This ( https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines) is great stuff. Is it OK to migrate it to the Contributor Info page that I created at the top level of the OpenDaylight Wiki? The page is: https://wiki.opendaylight.org/display/ODL/Contributor+Info. For now I have just created a single page for the "Best Practices" under the Contributor Info Page - all of the best practices should be ideally migrated over but for now I am just pointing to https://wiki-archive.opendaylight.org/view/BestPractices from this page. 

 

Thanks,

Abhijit

 

On Mon, Oct 19, 2020 at 5:55 AM Guillaume Lambert via lists.opendaylight.org <guillaume.lambert=orange.com@...> wrote:

Hi everyone

I completely share Robert's opinion here.
Robert, apart taking on my own some of the JIRA issues, I can try to give you a hand on guiding newcomers.
We faced these difficulties when beginning transportPCE. According to me, the 2 main problems are:
- most people do not know Gerrit  (and even Git) subtleties
  ( they are usually familiar with Github / GitLab PR which has a different philosophy)
- and as you pointed, best practices and step-by-step guides and other materials are spread over a lot of pages
   in our documentation, what fears potential contributors.
A few years ago, I tried my best to centralize the minimum material for newcomers in a page on our wiki,
now at https://wiki.opendaylight.org/display/ODL/Contributor+Guidelines
Though not obsolete, this page is a bit outdated because of latest Gerrit evolutions.
I am currently working  on it again to fill new needs, by listing some best practices for our contributors
and by simplifying openstack documentation, which is more complete than ODL on the topic in my opinion.
https://docs.openstack.org/openstack-ansible/queens/contributor/code-rules.html
https://wiki.openstack.org/wiki/GitCommitMessages
That can be good basis to start with.

Hope this helps
Guillaume

-----Message d'origine-----
De : release@... [mailto:release@...] De la part de Robert Varga
Envoyé : dimanche 18 octobre 2020 23:33
À : discuss@...; release@...; tsc@...; dev@...
Objet : [release] Drawing new contributors with simple tasks

Hello everyone,

this is yet another wall of text from me. TL;DR is: we want to give visibility of easy tasks so that even causal ODL users see where they can contribute.

If that interests you, please read on. If not and you'd like more relevant content from me, please unicast :)


We are faced with a dire lack of contributions, that is fact. We want to attract new contributors as much as possible.

Another fact is that we are being used in production environments, which sets the bar for contribution quality quite high.

This leads to competing requirements, where people willing to enter the community with a fix will be faced with dire requirements -- just because of the sensitive nature of the area they are touching.

We also lack the community resources to support on-boarding newcomers, most highlighted by our inability to grow the community via internships.

Being the top contributor (by more than a fair margin) who ends up doing all sorts of menial tasks, I think we need to start communicating the need, and receiving help with, a number of low-priority but nice-to-have-fixed issues.


One way of doing that is defining, labeling and publishing issues which we (the ODL community) know to be (relatively) easy to do, but are simply not of priority at a particular point in time.

For the definition part, I can say that filing a descriptive JIRA issue takes 5-10 minutes, where the effort required to solving it takes 4-16 hours.

For the labeling part, I took the liberty of defining a new label, 'quickwin', in JIRA. There a whooping one issue in https://jira.opendaylight.org/issues/?jql=labels%20%3D%20quickwin

What I struggle with is the question of communication -- and hence this wall of text (again, sorry, but heck there's so much context first!).

Can we perhaps create a documentation page for this?

My thinking is that it should be the first item under https://docs.opendaylight.org/en/latest/#opendaylight-contributor-guides
and would serve as the bare-bones, minimum-requirements, step-by-step HOW-TO of getting involved.

What do you think?

Regards,
Robert

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.