make github issues clearer?
Locked
make github issues clearer?
 
|
Hi everyone
Maybe it makes sense to generate some github issue templates and encourage people to fill in the related information from a prompt? I think with bug reports the situation is better, but for feature requests the state of things could be very much improved by adding a template that goes: "describe problem", "describe solution you'd like", "other alternatives", "additional context". Because right now github issues are a mess. I get it that some projects have particular maintainers and they know what the issues are and the phrasing doesn't matter, ok, but a lot of the issues that don't have a tie to any particular project and are labeled "easy" or "beginner" take a while to understand because you have no idea what the person who created the issue actually means. Just a suggestion, but i think there's really a lot of room to improve with labels and templates for issues, and make them more accessible to outsiders. Best, Myroslava |
Re: make github issues clearer?
|
|
+1 for improving the issues. I call that the "checkbox attitude": Opening an issue is mandatory for a change to be merged? No problem, i open an issue (just a title), check the box, et voilà... That's applying the letter of the law rather than the spirit of the law. Either the law is bad (too cumbersome for trivial changes?), or we are at degree zero of quality... I also call that quality-dry: It has the color of quality, the smell of quality, but it's not quality ;) Le lun. 28 oct. 2019 à 23:12, Myroslava Romaniuk via Pharo-dev <[hidden email]> a écrit :
|
Re: make github issues clearer?
|
|
Maybe this is possible with people with enough privilege to edit the issues in order to provide more details ? I try for the PolyMath project to have more elaborate labels: https://github.com/PolyMathOrg/PolyMath/labels with different status, priorities and types like describe here: but you need people to tag correctly issues and labelling is more complex. And I guess for Pharo, you will have to use a label to know what is the area of the system impact (like Compiler or UI). More people are needed to the triage of issues and polish them for sure. Regards, On Mon, Oct 28, 2019 at 11:23 PM Nicolas Cellier <[hidden email]> wrote:
-- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of Yaoundé I, Cameroon
|
Re: make github issues clearer?
|
|
In reply to this post by Nicolas Cellier
It actually is not mandatory anymore… and we should encourage people to just do PRs without opening an issue. (as the issue is really not useful in this case and tends to be empty).
I have added the robot that complaints when people do not add a description. This seems to help a little, as it forces people to add some explanation.
|
Re: make github issues clearer?
|
|
In reply to this post by SergeStinckwich
for that the Kanban boards are nice:
The problem is that GitHub only allows people with *write* access to the repo to add labels… or add issues to “projects”. They suggest to put the issue tracker into it’s own repo and give everyone write access there: Marcus
|
Re: make github issues clearer?
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
+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. |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
Hi! I think one of the problems is that not everybody can set labels. I've created a lot of issues but the only thing I can do is to set the description and title, even if I already know if it's a bug or feature, or the Pharo version it affects. For ba-st projects we have a set of standardized labels (see for example https://github.com/ba-st/Stargate/labels) and using it in every project makes it easy to filter them. AFAIR the permissions on GitHub are pretty crappy, so I think it's not possible to give permissions to external collaborators to change labels on issues without giving it write permissions over the repository. In any case having templates for bugs and feature issues sounds like a good idea. And I love the option to not have to open an issue if I will immediately provide a PR with code, because this avoids duplicating the discussion in two places. Best, Gabriel On Mon, Oct 28, 2019 at 7:13 PM Myroslava Romaniuk via Pharo-dev <[hidden email]> wrote:
|
|
|
In reply to this post by Torsten Bergmann
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 (<[hidden email]>) escribió:
|
Re: make github issues clearer?
|
|
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
|
Re: make github issues clearer?
|
|
In reply to this post by hernanmd
> On 4 Nov 2019, at 07:16, Hernán Morales Durand <[hidden email]> 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. |
Re: make github issues clearer?
|
|
In reply to this post by hernanmd
Le lun. 4 nov. 2019 à 07:17, Hernán Morales Durand <[hidden email]> a écrit :
Hi Hernan, could you ellaborate the problem you observe with the VM front? |
Re: make github issues clearer?
|
|
In reply to this post by ducasse
hi Stef On Mon, 4 Nov 2019 at 11:16, ducasse <[hidden email]> 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |