>
> 3. Let's have a "PR of the month" section :D
Great idea! :)
> In a past life (for the Meteor.js community), my team built a
> tool where people could submit, discuss, and vote on content
> newsletter-worthy content - and we automated emailing a summary of that
> weekly, which crowdsourced t
I agree we just need to take care of it as reviewers to inform the PR
authors.
On Thu, Sep 10, 2020 at 4:30 PM Ash Berlin-Taylor wrote:
> Yeah, that's what I do (or try to. No one is perfect.)
>
> I'm sure it's written down _somewhere_ but I've long since forgotten
> where I picked up that habit
Dear PMC,
I’m contacting you because your project has been selected by the ASF D&I
committee which is leading a research project to evaluate and understand
the current state of diversity in our community [1]. As part of this
research, we will analyze publicly available data about your project suc
I definitely prefer the "This commit when merged ..." rule than the
"imperative" one. It's so simple to remember ;).
And yeah - I mostly write the commit messages for the future self :).
And it's best if you describe the context the first time you push the
commit and make a draft PR - then the c
Yeah, that's what I do (or try to. No one is perfect.)
I'm sure it's written down _somewhere_ but I've long since forgotten
where I picked up that habit from. It's almost an extention to point 5
in https://chris.beams.io/posts/git-commit/#imperative (which we already
point to).
-a
On Sep 10 2020
We know the context _right_ now, but future us in 3 months will have
forgotten it all, so things we can do to help us remember what a PR
introduced the better.
(I also personally favour having the "PR description" in the commit
message, not just the PR, that way it's viewable even should we ever
d
Also on that, As far as I remember the "unwritten" rule that Ash mentioned
some time ago as far as I remember the "subject" of the commit is best if
it completes the sentence:
"This commit when merged " ("fixes this and that" for example).
And then the context on why we are doing it should fo
I agree with Jarek - as long as we cannot enforce it we as reviewers
should do our best to have the description in place.
On a general note, we should always remember that even if we know each
other and communicate through different channels (slack, calls, etc)
other people won't know the context
I am afraid people won't read it anyway. the PR template should be as
short as possible. I think this one is really something that should
be on reviewers. It's one of those things that is hard to automate or
delegate.
If the reviewer does not understand what the PR from the description,
it should
I think stalebot is not a good solution for Issues. It is good for PRs (PRs
age much faster than issues and usually if you have not touched the code
for a few weeks, it's better to start from the beginning, unless you
continuously upgrade and "refresh" it.
I do think, however (following what Elad
If I opened a bug report - what is the action expected from my side to keep
it alive?
Am I supposed to comment on it every 30 days?
Check https://github.com/apache/airflow/pull/10760 was picked after being
open for 3+ months.
Keep in mind that not always the person who reports the issue also has t
Maybe modify the template to include some copy from your email in it :)
On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik wrote:
> Hi all,
>
> I have brought this topic on multiple occasions earlier too on the mailing
> list. I sincerely request all the contributors and Committers (including
> myself) t
I'm not a fan of these bots for issues.
Yes, we have a lot of open issues, but I find it far more demotivating
to stumble across an issue on a project only to find it closed due to
inactivity -- even if it is still a problem.
-ash
On Sep 10 2020, at 1:22 pm, Ry Walker wrote:
> I agree that sta
I've seen it in other open source communities where someone tries to
maintain a somewhat detailed summary newsletter of what's going on with the
project, but weekly is a fairly brutal cadence, and it doesn't usually last
for long. In a past life (for the Meteor.js community), my team built a
tool w
Hi Sibarata -
I discussed your use case with some of our data engineers, we might have
some recommendations on how to better execute this - let us know if you
want to chat.
-Ry
Airflow Committer + Founder/CTO of Astronomer
On Mon, Sep 7, 2020 at 4:30 AM Sibabrata Pattanaik (spattana)
wrote:
>
I agree that stalebot is a best practice and we should use it, and 30d
sounds like a good starting point.
On Thu, Sep 10, 2020 at 7:56 AM Tomasz Urbaszek
wrote:
> Hi all,
>
> Currently, we have about 582 open issues on Github. The oldest opened
> in March. Do you think we should consider using s
Hi all,
Currently, we have about 582 open issues on Github. The oldest opened
in March. Do you think we should consider using stale bot as we do for
PRs?
I don't think that issue that is open since March is "so important" to
keep it still open. This would also automate the process of verifying
th
17 matches
Mail list logo
