-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Update the community PR message #288
feat: Update the community PR message #288
Conversation
Thanks for the pull request, @xitij2000! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
15d18ee
to
2de654f
Compare
Addresses #287 by implementing new welcome message for OSPRs. |
{% if owner %} | ||
This repository is currently maintained by `@{{ owner }}`. Tag them in a comment and let them know that your changes are ready for review. | ||
{% else %} | ||
This repository is currently unmaintained. To get help with finding a technical reviewer, tag the community contributions project manager for this PR in a comment and let them know that your changes are ready for review: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think unmaintained leaves a feeling of not being developed, when the project may still be actively developed but without an owner yet.
This repository is currently unmaintained. To get help with finding a technical reviewer, tag the community contributions project manager for this PR in a comment and let them know that your changes are ready for review: | |
This repository currently has no owner. To get help with finding a technical reviewer, tag the community contributions project manager for this PR in a comment and let them know that your changes are ready for review: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll let @itsjeyd chime in on this since the text draft comes from him. I'm guessing the idea is that every maintained repo should have an owner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing the idea is that every maintained repo should have an owner.
Yes that's right.
Before the maintenance working group was created and started reforming the concept of maintainership earlier this year, things were a lot fuzzier -- there was the concept of (edX/2U) code ownership, which didn't really include the responsibilities that you'd expect a maintainer to take on, and a separate concept of maintainership (as defined in the context of the Maintainership Pilot program). For some repos, the two would overlap (i.e., edX/2U officially owned these repos and also signed on as a maintainer in the context of the pilot), and for others they didn't. That was creating confusion and contributing to delays in the OSPR review process.
Of late there's been a tendency to standardize on "maintainer" terminology, so I think I was trying to follow that here and avoid falling back on "code ownership" language.
... unmaintained leaves a feeling of not being developed, ...
I do agree with this, though. Since the goal is to eventually get to a point where all relevant repos are under active maintenance, maybe it would help to meet in the middle and say something like:
This repository has no maintainer (yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can use more cues from the catalog file here. The lifecycle should indicate if the repo is in production, experimental or deprecated. For deprecated repos we can confidently say that the repo is unmaintained, whereas for a production repo we can use the above language. Does that sound better or should be keep things simple?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xitij2000 Sounds good to me, more nuance would be great 👍 CC @mphilbrick211 ⬆️
GitHub pull request interface. As a reminder, | ||
[our process documentation is here](http://edx-developer-guide.readthedocs.org/en/latest/process/overview.html). | ||
{% endfilter %} | ||
Thanks for the pull request, `@{{ user }}`! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is the user in back ticks now? i see that it works ok without them right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure, but I've taken the contents from here.
Generally, the idea with putting it in backticks is to avoid actually pinging the user. However, in this case perhaps the user should be notified?
@itsjeyd Should the backticks be here? I think not notifying the maintainer group or user makes sense but the PR author perhaps should be OK to ping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xitij2000 @DanielVZ96 I don't remember why I added those backticks, feel free to remove them 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xitij2000 @itsjeyd i also prefer the ping 😅
Hey @xitij2000, could you have a look and see what's keeping the tests from passing here? Once the build is green we'll be able to move forward with engineering review. (Commenting as OSPR manager right now :)) |
It's a known issue with rate limits when uploading coverage. The tests themselves have passed. I don't know if an admin running the tests will bypass this. |
@xitij2000 OK I see, we should be good to put this up for review then. @feanil This is the PR that updates the OSPR welcome message that we discussed in the maintenance working group a while back. Would you be able to review it? Happy to ping someone else if you don't have bandwidth, please let us know. |
Hey, all. Sorry for the quite, I am planning on reviewing this, this week. |
Great, thanks @feanil. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xitij2000 @itsjeyd thank you for being so soooo patient. The changes look great, I just had one question related to formatting and then I think this is good to land.
@@ -1,52 +1,105 @@ | |||
{% filter replace("\n", " ")|trim %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this removed? Do we believe that it's not necessary anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That filter was being applied in sections where newlines were added in the original document for wrapping but were not supposed to be present in the output. In the new document the placement of newlines in significant and is supposed to be retained in the output.
Also, the coverage test failure should be resolved now if you rebase the PR. |
This change updates the community PR message to provide better guidance and updated links to the latest documentation. The message now also directs contributors to the correct team or person to tag to get their PR reviewed and merged.
c99eebe
to
6121962
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #288 +/- ##
==========================================
+ Coverage 89.76% 89.90% +0.13%
==========================================
Files 38 38
Lines 2882 2921 +39
Branches 397 407 +10
==========================================
+ Hits 2587 2626 +39
Misses 268 268
Partials 27 27 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, I don't think I'll have time to ship the code today but I'll ship this onto the testing server as soon as I can.
Ok, changes have been tested here: openedx-unsupported/mdrst#40 and openedx-unsupported/mdrst#41 I'm merging and pushing this to production. |
@xitij2000 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
Change is deployed to production, thanks for all the hard work everyone, appreciate your patience as always! |
Happy to see this land, thanks @feanil! |
This change updates the community PR message to provide better guidance and updated links to the latest documentation.
The message now also directs contributors to the correct team or person to tag to get their PR reviewed and merged.