With all due respect, this makes commenting on a PR much more painful. In Github, someone can click a line and leave a comment. It’s pretty simple and easy.
To leave a comment on the forum, one needs to select a line, copy the context/content, add a comment, mess with formatting, etc. Then switch back to the material and remember where you were reading from. There’s is a much higher overhead, and that additional work isn’t very conducive to maintaining state about what you were reading.
Hi, the reason we use the forum is because of @iHiD decisions to move stuff from github to the forum. I am not the person who made the decisions I am simply following them.
What should also be added is the pr is already merged since we are only looking for feedback. I also have a hard time seeing you have so much to point out that you couldn’t put it on the forum. Since that would kinda imply that you find an issue every other line.
If you like to discuss the matter further please speak with @iHiD.
Yes. I know. I read the OP iHiD is active on this topic so my comment is open for his response as much as for yours.
Yeah. Given that it’s already merged, that does make it harder to use GitHub for reviews. Though maybe it might make sense to solicit feedback prior to merging so the GitHub review tools could be leveraged.
This sounds a bit passive aggressive to me, though I might be reading it wrong. I’m not attacking you. I’m providing feedback on the tooling being used here.
You’re welcome to look at my other PR reviews. Often I do have a lot of comments. I don’t need to have a comment for every other line for this to feel onerous; even if I only had 6 components, I think using proper review tooling would make life simple.
Additionally, I’m not the only one being asked for feedback here. There had been other feedback earlier in this topic which addresses multiple lines.
This line of rhetoric is not conducive for productive discussion. It’s one thing to suggest this line of discussion is derailing the topic and might benefit from being split into it’s own topic (which I believe is one of Discourse’s more interesting features). Telling someone to take their feedback elsewhere shuts conversations down in an unproductive manner.
I’ve separated this into it’s own topic.
@IsaacG doesn’t think giving feedback here compared to GH is great.
@meatball is just doing what is inline with current Exercism guidelines and doesn’t want to discuss that pros/cons specifically.
So firstly, this is the sort of issue we need to resolve over the next few months and why we’re pausing community contributions, as so many conversations derail to some variant of frustrations from contributions/maintainers/reviewers. I don’t know the answers, which is why we’re pausing stuff right now.
The whole PR review stage is what’s killing big tracks (its consistent across all big tracks) and so I’m in favour to a large extent of getting an minimal version of an exercise over the line that a maintainer feels is appropriate, then having the PR discussions on the improvements/suggestions, rather than on the core thing. Else we end up with these long drawn-out conversations that’s killing all momentum and joy.
In this interim phase, when we do want people to be able to add exercises and move forward in a relatively autonomous fashion. Bethany and Carl worked on this exercise to get it over the line, so a maintainer has checked and approved this, and I’m happy that a basic version got merged without a painful PR.
I therefore feel that the suggestion of providing general feedback on the forum is good I think because general feedback isn’t specific to lines of code (there will be some where things don’t make sense). For specific things that need tweaking, I think we need follow-up PRs to fix things and the discussion on this. However, I’d add that it’s equally the maintainers that merged the MVP of the initial exercise with an optimistic-merging attitude then need to have that same optimistic-merging attitude to improvements too.
I’m going to bed now, but we can discuss this more next week if needed. It’s a hard subject and don’t have the answers. In the meantime, @IsaacG and @Meatball - let’s both presume each are speaking with best intentions and attitudes pls - you both want the same thing, which is a fun experience of making the Python track great
This discussion stemmed from an explicit request for feedback on a new exercise. So, it sounds like the goal is to (1) allow the PR to be merged prior to broader feedback but then (2) receive broader feedback on the PR so subsequent improvements can be made.
The first goal can be achieved by merging the PR prior to requesting broader feedback.
Having the PR merged prior to requesting broader feedback makes it tricky to use GitHub’s tooling to get feedback on the PR. Hence using the forum for broader feedback.
I’m wondering if it would make sense to use something like a git “feedback” branch, which can be branched from
HEAD~1 then have the same PR applied to it, so that the broader feedback can be done via GitHub and with the GitHub tooling, but after the PR is already merged. Does that make any sense?
Another point with regard to using GitHub vs the forum for feedback: with GitHub, it’s easy to see if there are existing comments on a specific sentence or paragraph. With the forum, it can be much harder to see if something specific was already commented on. Prior to making a comment on some line, the reviewer would have to read all the prior comments and check if that specific item was called out.
Both GitHub and the forum has the issue that larger reviews can take a while for people to review and write up comments. Concurrent reviews can comment on the same issue. This can be circumvented with GitHub by leaving individual comments vs a “review”.