Dear all,
It’s again time to organise our next monthly call which will be in the week of November 15-19; please see the following doodle poll to mark your availability:
The final time slot will be selected and announced on the evening (European time) of Monday November 8, please complete the poll before then .
If there are specific topics or issues you would like to raise, even if you are unable to attend the call, please post them in the thread here.
All the best,
Jeremie
2 Likes
Don’t forget to complete the poll, and to add your topics/issues
Our next monthly call will be on Monday, November 15 at 20:00 UTC .
12:00 - 13:00 PDT (California)
As previously, the meeting will be recorded for those who cannot attend.
Please continue to use this thread for topics you would like discussed at the meeting.
A Zoom invitation will follow soon.
Note: Anyone who is interested is welcome to join!
2 Likes
Thank you, Jeremie! Here’s the Zoom info:
Topic: Fortran Monthly Call
Join Zoom Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Meeting ID: 965 7477 2624
Dial by your locationZoom International Dial-in Numbers - Zoom
Join by SIP96574772624@zoomcrc.com
Join by H.323
1 Like
In a few hours, our Fortran Monthly call will start. Don’t hesitate to add items to the agenda.
Possible item: How to attract reviewers for stdlib?
1 Like
Arjen
November 15, 2021, 3:36pm
6
I would like to discuss the issue of Windows installers - we seem to be making progress there, so I would like to hop on with my tentative GUI.
2 Likes
I’d like to discuss the bug report templates for Fortran-lang projects (stdlib, fpm), and request feedback from everybody on the call. For context, please read the discussion in:
opened 02:32AM - 13 Nov 21 UTC
question
meta
Here's what the bug report form looks like: https://github.com/fortran-lang/stdl… ib/issues/new?assignees=&labels=bug&template=01_bug.yaml
and the PR that implemented it: #513
In #561, @certik wrote:
> This form is so hard to fill out that I almost gave up on reporting this.
>
> I would suggest to either get rid of it, or simplify this.
Ondrej, can you explain why was it so hard to fill out? I'm looking at the #561, and it seems like if it weren't for the form you'd still write out all the same information. Do you agree?
I opened this issue to find out how we can improve it. As I see it, this form is as simple as it can get. I think that any issue that contained less than the required information would be incomplete. Let's look at it field by field:
* **Title**: Required by GitHub
* **Description**: We don't have an issue without this field.
* **Expected behavior**: This could be redundant in scenarios where the issue is that "it doesn't build", and the answer is the obvious "it should build". So, perhaps we could make this one optional.
* **Version**: Necessary for reproducing. Many newcomers are not aware that this is important.
* **Platform and architecture**: As with version.
* **Additional information**: Of all, this one seems the most redundant but it's also optional. I think we could get rid of it, as any additional information could be written in the "Description" field.
I've opened issues in in many terribly long templates, and even walked away from some because they were too much work. But this template is by far among the simplest I've seen. Nevertheless, we can still improve it and we should lower the bar as much as we can while still requiring the info we need. To that end, I suggest to:
1. Make "Expected behavior" an optional field
2. Remote the "Additional information" field.
What do you think?
I will be available for the first 30 minutes of the call due to another meeting, so it’d be great if we can discuss this one first.
1 Like
@milancurcic : we will start with your topic!
Current agenda:
1) stdlib
* How to improve the bug report template? (@milancurcic)
* How to attract reviewers? (@jeremie.vandenplas)
2) Windows compiler and GUI (@Arjen )
jeremie.vandenplas:
How to attack reviewers?
I think we want to “attract” reviewers, not attack them.
2 Likes
