Re: [Pharo-dev] make github issues clearer?
This is it. Finally this problem is spotted. It's been years since I read a Pharo issue because of their targeted "narrative" to a bunch of 5 - 10 people who share a daily operational knowledge. This is more severe with the VM front. Other communities, like R, use a lot minimum reproducible example (MRE). So nothing new should be invented here, if Pharo just could adopt one of the standard practices... Cheers, Hernán El mar., 29 oct. 2019 a las 8:56, Torsten Bergmann (<astares@gmx.de>) escribió:
+1000
I've seen this several times that issues where just a short title only "wizards" were able to understand
The "Full description requires time" is not an argument here. We all should get more professional and disciplined here - so anyone is able to reproduce and understand what an issue is about. This will also increase the trust into Pharo and its dev process...
Bye T.
I can tell you that it is even hard for me to understand some issue tracker entries. We really need to find a way that people add better information. For me one thing I will try to do: to not use the issue tracker anymore as my private TODO list. This means that the âI should maybe look into this but i have no time to even add a descriptionâ entries are now in my private list and if I make an issue on the issue tracker I will try to write it in a way that it explains how someone else could fix it. Marcus
On 4 Nov 2019, at 07:16, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
This is it.
Finally this problem is spotted. It's been years since I read a Pharo issue because of their targeted "narrative" to a bunch of 5 - 10 people who share a daily operational knowledge. This is more severe with the VM front.
Other communities, like R, use a lot minimum reproducible example (MRE). So nothing new should be invented here, if Pharo just could adopt one of the standard practices...
Cheers,
Hernán
El mar., 29 oct. 2019 a las 8:56, Torsten Bergmann (<astares@gmx.de <mailto:astares@gmx.de>>) escribió: +1000
I've seen this several times that issues where just a short title only "wizards" were able to understand
The "Full description requires time" is not an argument here. We all should get more professional and disciplined here - so anyone is able to reproduce and understand what an issue is about. This will also increase the trust into Pharo and its dev process...
Bye T.
On 4 Nov 2019, at 07:16, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
minimum reproducible example (MRE).
+100 I am not sure that it needs a name (never heard it), but this should be so obvious. Of course there has to be code that shows the issue, as simple as possible. BTW I hate it when people explain their issue by saying: load a couple of complex projects, install some other software and then run it 10 times and it will probably happen.
Yes sometimes describing it takes more time than fixing it. I would encourage people complaining to participate more. (no need to tell me that if we do not describe then people cannot get it). At the end of the day, the key point is to contribute for real. Stef
minimum reproducible example (MRE).
+100
I am not sure that it needs a name (never heard it), but this should be so obvious.
Of course there has to be code that shows the issue, as simple as possible.
BTW I hate it when people explain their issue by saying: load a couple of complex projects, install some other software and then run it 10 times and it will probably happen.
hi Stef On Mon, 4 Nov 2019 at 11:16, ducasse <stepharo@netcourrier.com> wrote:
Yes sometimes describing it takes more time than fixing it.
if that is the case, then maybe you should just fix it. easy issues are cool in theory but if they are not sufficiently explained they will not be of any use to beginner devs who want to contribute, either. if you are creating an easy issue and marking it 'beginner', the description should be level-appropriate. and in general there are templates that make this whole process easier/faster because you have some things pre-filled and you have section descriptions that helps you quickly remember the things you need to describe. my whole point was about optimising this process on the org level: individual contribution certainly counts for something, but there's no need to reinvent the wheel. best, Myroslava
participants (7)
-
ducasse -
Hernán Morales Durand -
Marcus Denker -
Myroslava Romaniuk -
Nicolas Cellier -
Sven Van Caekenberghe -
Torsten Bergmann