[INFRA] add github issue form

[Remi-Gau]

fixes #5

I am using my fork as a demo (switched the default branch to show case it)

• submission form rendering: https://github.com/Remi-Gau/global2021/issues/new?assignees=&labels=project&template=project-submission-template.yml&title=%5BProject%5D%3A+

• example output: https://github.com/Remi-Gau/global2021/issues/2

---

To do

• improve descriptions and place-holders
• adapt content to the Google form version

---

decisions needed

• which items will be "required"?

We need to decide which items need to be filled in for people to be able to click 'submit new issue'. I am tempted to set the bar fairly high (also because sections that are not filled in do not appear in the opened issue).

[Remi-Gau]

@jhlegarreta @complexbrains

[jhlegarreta]

@Remi-Gau tremendous work. 💯 to having considered the label fields and made them drop down menus. Will have a more detailed look tonight, will create the labels and start having a look at how these things can be parsed to get the relevant data.

[Remi-Gau]

@Remi-Gau tremendous work.

thanks

100 to having considered the label fields and made them drop down menus. Will have a more detailed look tonight, will create the labels and start having a look at how these things can be parsed to get the relevant data.

Do you think we should add special character before each label in the dropdown menus ? I think the original template used #.

This could make it easier for parsing and should not be too confusing for the users. What do you think?

[jhlegarreta]

Do you think we should add special character before each label in the dropdown menus ? I think the original template used #.
This could make it easier for parsing and should not be too confusing for the users. What do you think?

The issue labeler action seems not to require them, so not sure why they were required. I do not see how they should help for the current form.

[Remi-Gau]

Ok let's proceed like that for now and see when things start catching on fire or when the wheels are coming off. Written from my phone. Preemptive apologies for the brevity and typos.

…

________________________________ From: Jon Haitz Legarreta Gorroño ***@***.***> Sent: Tuesday, September 28, 2021 5:19:32 PM To: brainhackorg/global2021 ***@***.***> Cc: Remi Gau ***@***.***>; Mention ***@***.***> Subject: Re: [brainhackorg/global2021] [INFRA] add github issue form (#32) Do you think we should add special character before each label in the dropdown menus ? I think the original template used #. This could make it easier for parsing and should not be too confusing for the users. What do you think? The issue labeler action seems not to require them, so not sure why they were required. I do not see how they should help for the current form. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#32 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABVDQIN2DQEAG2OPADL7DVLUEHMIJANCNFSM5E3IPAQQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Remi-Gau]

Actually the # is needed for the issue labeller and not the issue to project parsing:

https://github.com/brainhackorg/global2021/blob/main/.github/labeler.yml

[jhlegarreta]

Actually the # is needed for the issue labeller and not the issue to project parsing:
https://github.com/brainhackorg/global2021/blob/main/.github/labeler.yml

I missed the dictionary although I think I opened the file 🤦 . Labeling the issues was also a requirement last year so that issues could be easily filtered. I guess this is the case this year as well. Adding a heading hashtag to the drop down menus would look weird IMHO. Also, I'm not sure whether the labeler works on the YAML file. I'll create labels tonight and see if if the labeler works for an issue.

[jhlegarreta]

Labels created. Just in case we need them again, here they are:
bhg_gh_labels.json.txt

[jhlegarreta]

@Remi-Gau a few thoughts after having had a look:

• To actually see if the labeler is working, we would need this to be merged: I cannot create labels in your repository.
• I think the hashtags last year were used because all list values existed in the issue template: the way to distinguish those required by a project was by adding a hashtag to those elements, and then the labeler had it matches. Not sure what the raw text looks like for an issue with the proposed template, so I cannot tell whether the labeler will get them right.

Opening a bunch of issues here for testing would clutter things IMO, so @Remi-Gau would you upload the labels to your fork (or provide me with rights to add labels) to see if the above works ??

Other than that, IIUC, two things are left (and again, we would need to open issue to test these):

• see if the issue to pages workflow is working with this template, and if not, how to fix it. The repository URL will be one thing to change. The action should be triggered when an issue is opened, so that will cast light on its potential issues.
• generate a tsv file for each project in the issues for the brainmatch script. The pull_issues.sh script was developed for that, based on the data format provided in last year's issues. I assume it will not work with the proposed template. But I cannot tell how it will fail.

These two scripts might have things in common, like getting the issues from gh. One is written in Python, the other one is a shell script. IMHO the cost of maintaining the two in non-negligible. Also taking into account #25. So it looks like one way or the other (Python vs shell) needs to be decided. Not sure if @eurunuela happens to have another proposal.

I'm approving so as to get things going forward. Issues with the template can be fixed in separate PRs.

[eurunuela]

These two scripts might have things in common, like getting the issues from gh. One is written in Python, the other one is a shell script. IMHO the cost of maintaining the two in non-negligible. Also taking into account #25. So it looks like one way or the other (Python vs shell) needs to be decided. Not sure if @eurunuela happens to have another proposal.

I think we should translate the shell script into Python. IMO that's the easiest way going forward considering #25. Since I wrote the pull_issues.sh script, I will open an issue in the brainmatch repository and will take care of translating it into Python.

[Remi-Gau]

I think we should translate the shell script into Python. IMO that's the easiest way going forward considering #25. Since I wrote the pull_issues.sh script, I will open an issue in the brainmatch repository and will take care of translating it into Python.

Agree to use Python as glue for everything.

[Remi-Gau]

@Remi-Gau a few thoughts after having had a look:

* To actually see if the labeler is working, we would need this to be merged: I cannot create labels in your repository.

* I think the hashtags last year were used because all list values existed in the issue template: the way to distinguish those required by a project was by adding a hashtag to those elements, and then the labeler had it matches. Not sure what the raw text looks like for an issue with the proposed template, so I cannot tell whether the labeler will get them right.

Opening a bunch of issues here for testing would clutter things IMO, so @Remi-Gau would you upload the labels to your fork (or provide me with rights to add labels) to see if the above works ??

I'm approving so as to get things going forward. Issues with the template can be fixed in separate PRs.

OK so I will merge this here and we test things on my repo once I added the labels.

* see if the `issue to pages` workflow is working with this template, and if not, how to fix it. The repository URL will be one thing to change. The action should be triggered when an issue is opened, so that will cast light on its potential issues.

I guess this can be tested on my side too, no?

[jhlegarreta]

I guess this can be tested on my side too, no?

Yep.

[jhlegarreta]

By opening an issue in Rémi's fork I've realized that if a file is dropped in one of the fields that is not expected to contain anything other than text, we might run into issues when trying to generate the project data for the workflow.

[jhlegarreta]

I ran the script in PR #40 on the repository here
https://api.github.com/repos/Remi-Gau/global2021/

and leaving apart the status:published filtering, the issue data got parsed without breaking for the existing issue. A few notes, though:

• The issues have two titles, one corresponding to the GitHub issue title, the other one in the body, corresponding to the field in the form. BHG 2020 had two as well. Might need to be considered at some point/later time if it happens to be misleading. The script only looks at the GitHub issue title.
• For the sake of minimizing the effort, being consistent across year and not breaking things:
  • I would rename the Description field to Project Description in the issue form. If you think that is should not be, the regex should be changed in the script.
  • Same goes for the Link to the project field: the old template had Link to project repository/sources as title.
    Otherwise, the names should be agreed upon once for good.
• The issue template title has a default [Project]: text: if not deleted, it will appear in the title field. I would remove it; if not, all project sections on the website will have it.
• The labeler is not working due to this line, and thus the issue is not getting labels, which is relevant for the website project data and brainmatch. Modifying the date to allow the labeler do its job, and assuming the label dictionary gets the appropriate changes (e.g. hashtags removed and regex refined maybe to avoid undesired hits), the script in PR ENH: Refactor issues to pages script #40 would get the labels without requiring changes.

The regexes may need to be adjusted to look for ### {field_name} to ensure that the field hit is the desired one: e.g.
(?<=### Description[^\v]{2})(.*)(?=[^\v]{2}###) would catch the data in the description (tested).