Easy first issues for Pharo contributors?
Hi Pharo developers, I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues. Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones. My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful). James Foster
On 6 Oct 2019, at 07:04, James Foster <Smalltalk@JGFoster.net> wrote:
Hi Pharo developers,
I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues.
Excellent idea!
Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones.
It would be super cool to add executable examples to number and others.
My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful).
Yes. Once back in 2005 I gave as exercise to write tests for collections (because they were none back then) after I reviewed revise them and committed them. So looking at coverage of classes may be a nice option too. I think that what you can also ask them is to - reproduce issue - comment issue This is an important aspect too. Stef
James Foster
All good suggestions. I especially like the executable examples idea since that will demonstrate understanding of the code but still be easy to describe and easy to confirm. Thanks!
On Oct 6, 2019, at 3:10 AM, ducasse <stepharo@netcourrier.com> wrote:
On 6 Oct 2019, at 07:04, James Foster <Smalltalk@JGFoster.net> wrote:
Hi Pharo developers,
I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues.
Excellent idea!
Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones.
It would be super cool to add executable examples to number and others.
My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful).
Yes. Once back in 2005 I gave as exercise to write tests for collections (because they were none back then) after I reviewed revise them and committed them. So looking at coverage of classes may be a nice option too.
I think that what you can also ask them is to - reproduce issue - comment issue This is an important aspect too.
Stef
James Foster
On Sun 6 Oct 2019 at 16:12, James Foster <Smalltalk@jgfoster.net> wrote:
All good suggestions. I especially like the executable examples idea since that will demonstrate understanding of the code but still be easy to describe and easy to confirm. Thanks!
Hi, Adding method, class and package comments is also simple and great for the community :)
--
Cyril Ferlicot https://ferlicot.fr
Stef, I see that you added executable comments tasks to the âSimple Issues for Beginnersâ project. Thanks! Another idea I had is method category cleanup. While there is some judgment involved in many of the category names, I see several names that are misspellings (starting with 'accessingâ). I donât know if you want to add a task for that as well, or we can just open pull requests. James
On Oct 6, 2019, at 7:11 AM, James Foster <Smalltalk@JGFoster.net> wrote:
All good suggestions. I especially like the executable examples idea since that will demonstrate understanding of the code but still be easy to describe and easy to confirm. Thanks!
On Oct 6, 2019, at 3:10 AM, ducasse <stepharo@netcourrier.com> wrote:
On 6 Oct 2019, at 07:04, James Foster <Smalltalk@JGFoster.net> wrote:
Hi Pharo developers,
I have a few undergraduate students taking OO programming and Iâm using the Pharo MOOC to get started. One of the goals in our CS program is to get students familiar with a development process using Git, so we require contributions to an open source project is a few classes. Iâd like to assign a Pharo contribution and am looking for easy first issues.
Excellent idea!
Iâll take a look at the issues marked âEasyâ as well as the âSimple Issues for Beginnersâ project, but would welcome additional ones.
It would be super cool to add executable examples to number and others.
My current thought is to go through tests looking for use of #âassert:â that could be changed to #âassert:equals:â. I view this as being an improvement but still quite safe and easy to describe. Most of the work will be setting up the environment and going through the development cycle; I want the actual coding to be minimal (but still useful).
Yes. Once back in 2005 I gave as exercise to write tests for collections (because they were none back then) after I reviewed revise them and committed them. So looking at coverage of classes may be a nice option too.
I think that what you can also ask them is to - reproduce issue - comment issue This is an important aspect too.
Stef
James Foster
On 11 Oct 2019, at 06:20, James Foster <Smalltalk@JGFoster.net> wrote:
Stef,
I see that you added executable comments tasks to the âSimple Issues for Beginnersâ project. Thanks!
Another idea I had is method category cleanup. While there is some judgment involved in many of the category names, I see several names that are misspellings (starting with 'accessingâ). I donât know if you want to add a task for that as well, or we can just open pull requests.
Yes I have a little tool for that the automatic method categorizer It has some methods for doing analysis and also fixing system wide problems. Stef
participants (3)
-
Cyril Ferlicot -
ducasse -
James Foster