Mailman 3 - core-workflow

Hi everyone
by giuongngugotunhienla＠gmail.com 13 Aug '20

13 Aug '20

I am an interior designer from Vietnam. I am currently working at Lac An Furniture Company. Here is its website address: https://lacan.vn/. Hello everyone, everyone a happy working day!

2 1

Mail list
by Daniel Scott 16 May '20

16 May '20

Sent from Yahoo Mail on Android

1 0

Core Workflow change: new commit to previously approved PR now requires re-review
by Mariatta 16 May '20

16 May '20

X-post to python-committers, python-dev, and core-workflow mailing list I have just deployed a change to bedevere-bot to address the security concern related to automerging.( https://github.com/python/core-workflow/issues/325) Previously, if core dev has approved the PR and applied the "automerge" label, the PR will be automatically merged as soon as all the required CI checks passed. If the PR author added another commit after the PR has been approved but before the automerge happened, the additional commit will get merged in without additional review. Now, if there is a new commit after the PR has been approved, it will not be automerged until the the core dev re-reviews it. bedevere will remove the "awaiting merge" label and apply the "awaiting core review" label. Hope this all makes sense. And if you see any of the bot misbehaving, please open a ticket either in core-workflow repo or in the bot's own repo. Thanks.

2 1

Proposal for creating github spellcheck bot.
by Chen KunYu 02 Sep '19

02 Sep '19

Hi, Recently, tirkarthi (xtreak) works on finding and fixing typos. And I (18z) came up with the idea of creating a spellcheck bot to improve the quality of cpython. We had discussion in https://github.com/python/cpython/pull/13749 And it is summarized below: Consensus: - Reducing typo in a constructive way. To be Solved: - Even after reducing the code checked, there will still be mostly false positives. - High frequency of updating dictionary.txt (false positive typo). Next Step: - Interfacing the filter with aspell to get some numbers. MISC: - The report could be made optional with a spellcheck label. - Code for reducing .py files to strings and comments. - Command line for spellcheck. There are problems to be solved. But I think we can always find a better solution. So, I’ll be working on interfacing the filter with aspell to get some numbers. Looking forward to hearing more opinions. :D Thanks KunYuChen (18z)

6 8

PEP 581/588 RFC: Collecting feedback about GitHub Issues
by Mariatta 27 Aug '19

27 Aug '19

(cross posting to python-committers, python-dev, core-workflow) PEP 581: Using GitHub Issues has been accepted by the steering council, but PEP 588: GitHub Issues Migration plan is still in progress. I'd like to hear from core developers as well as heavy b.p.o users, the following: 1. what features do they find lacking from GitHub issues, or 2. what are the things you can do in b.p.o but not in GitHub, or 3. Other workflow that will be blocked if we were to switch to GitHub today By understanding your needs, we can be better prepared for the migration, and we can start looking for solutions. In addition, I received tip that the GitHub team is very motivated to help us, and if we can give them some of our most wanted features, they *might* be able to accommodate us. But first we need to tell them what we need. They're not promising anything, but I'd like to at least try and give them these suggestions. Action items: 1. Please leave your comment in this issue: https://github.com/python/core-workflow/issues/359 2. Leave your +1 by reacting 👍 to suggested feature by others 3. Please do this before October 1, 2019 (not a hard deadline) Thanks ᐧ

1 0

Re: [Python-Dev] Re: 🍝 New keyword in bpo: `newcomer friendly`
by Guido van Rossum 29 Jul '19

29 Jul '19

See the thread 'The trouble with "Easy" issues' in core-mentorship(a)python.org. Essentially those "easy" issues aren't so easy, and we're starting over. (That list requires subscription before you can read it, but any core dev should be able to get a subscription.) On Fri, Jul 26, 2019 at 6:58 PM Skip Montanaro <skip.montanaro(a)gmail.com> wrote: > > There is now a “newcomer friendly” keyword in bpo. > > > > My hope is that going forward, we can tag issues that are suitable for > first time contributors with this keyword. > > Hmmm... I haven't looked lately, but didn't there used to be an "easy" > tag which purported to serve roughly the same purpose? I see an "Easy > issues" link in the left-hand sidebar: > > > https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivi… > > This issue has the "easy" keyword: > > https://bugs.python.org/issue19217 > > Are "newcomer friendly" and "easy" aimed at somewhat different targets? > > Skip > > > Skip > _______________________________________________ > Python-Dev mailing list -- python-dev(a)python.org > To unsubscribe send an email to python-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7C6WTTB… > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

3 3

🍝 New keyword in bpo: `newcomer friendly`
by Mariatta 27 Jul '19

27 Jul '19

🍝 copy-pasta from core-mentorship mailing list. There is now a “newcomer friendly” keyword in bpo. My hope is that going forward, we can tag issues that are suitable for first time contributors with this keyword. It would be great for experienced contributors already familiar with our workflow to not work on issues tagged with newcomer friendly and leave that to new contributors. I’ve added the keyword to Devguide’s Triaging section, with additional guideline of what can be tagged as newcomer friendly. Typically it should be straightforward, well-defined issue, and low-risk. https://devguide.python.org/triaging.html#keywords Thanks. ᐧ

2 1

Using CLA-assistant for Python
by Mariatta Wijaya 06 Mar '19

06 Mar '19

Following up from past thread about Improving CLA signing process ( https://mail.python.org/mm3/archives/list/core-workflow@python.org/thread/2… ) Over in Zulip <https://python.zulipchat.com/#narrow/stream/130206-pep581/subject/CLA/near/…>, Yury suggested using cla-assistant <https://github.com/cla-assistant/cla-assistant>, which he used in EdgeDB project. I've checked with Van, and from legal point of view, he has no problem with using cla-assistant, and he said that he can do what is needed to support it. Brett and Zach both sounds supportive too. *question*: Is there any objection if we start using cla-assistant instead of the-knights-who-say-ni? (I'm going to take silence as :"no objection" :) ) What we will need to do order to start using cla-assistant: - Export the currently signed cla info from bpo to cla-assistant. We need to come up with a .csv containing a list of GitHub usernames of people who has signed Python's CLA. - Create a GitHub gist that represents Python's CLA and any additional info we need (some instruction here <https://github.com/cla-assistant/cla-assistant#request-more-information-fro…> ) - Install cla-assistant in Python organization on GitHub, and enable it for the various repositories: cpython, devguide, peps, core-workflow, bedevere, miss-islington. Perhaps we start with just devguide at first, and see how it goes. - Update documentation surrounding CLA signing process. - Make the cla status check required. - We can remove the CLA signing page <https://www.python.org/psf/contrib/contrib-form/>, or keep it up only for those who submits patch to bpo - check-python-cla.herokuapp.com can be shut down, there will be no more use of it. - I think we can stop maintaining the-knights-who-say-ni? Things that we will lose if we go with this new workflow: - Since cla-assistant works with GitHub usernames, people who has signed the CLA but did not associate their GitHub username will need to either associate their GitHub username before the move, or sign the CLA again once the move. - since the cla status check will be required, we may not be able to "ignore" - Since the status check will be made required, it means every contribution no matter how trivial, requires CLA. Without it, we can't merge the pull request. (Maybe only the admins can still merge). Sounds like this is a good thing anyway (for Python). - It can't check the CLA for people who contribute by submitting a patch in bpo. I guess in this case, we will fallback to the cla record in bpo. This situation should be quite rare. Most of us prefer GitHub PRs over bpo patch. - Any other issue I didn't think of? If nobody has strong objections or raised any issues, I plan to get this started and set up during Core sprint in a couple weeks. I'm hoping we don't have to wait until we have the next BDFL/COP/TOP*/voting committee to decide on this. *acronyms: BDFL: Benevolent Dictator For Life COP: Council of Pythonistas TOP: Trio of Pythonistas ᐧ

8 11

"Awaiting merge" label for PRs from core devs
by INADA Naoki 01 Mar '19

01 Mar '19

Hi. When core dev creates PR, "Awaiting merge" label is set automatically. It makes many "awaiting merge" PRs. It makes the label less useful, in my opinion. How about stop setting the label automatically? If the author wants review from other core-devs, they can set "awaiting core review" label manually. Other option is set "awaiting review" label instead of "awaiting merge", like PRs from other contributors. Regards, -- INADA Naoki <songofacandy(a)gmail.com>

6 10

Re: [Python-Dev] Get a running instance of the doc for a PR.
by Mariatta Wijaya 12 Feb '19

12 Feb '19

[Added core workflow and removed python-dev] Original thread: https://mail.python.org/pipermail/python-dev/2018-November/155651.html On Sun, Nov 11, 2018, 6:37 AM Stephane Wirtel <stephane(a)wirtel.be wrote: > Mariatta, > > Do you think we could add a webhook for the build of the documentation > for each PR where the build of the doc works? > I can setup webhooks for CPython. Do you have the URL for the webhook? Or is this still in development? >

1 2