How do projects join?

[sigmavirus24]

I mentioned this recently but I'm basically the only person who responds to requests to add things to the PyCQA and works on the process. There's room for automation around it and it would be good if it wasn't just me making decisions.

Vaguely my criteria thus far have been:

• Is this a project that's been around a while (not a few months that no one's heard of and the author is trying to boost credibility) and might benefit from being able to not have a single person owning it

• Is this project related to code quality in some way? (Linter, auto-formatting, etc.)

• Do the folks involved seem like folks that might push others away?

[sigmavirus24]

I think #42 is advocating that new projects be using main as their default branch before being included. I don't think that counts as criteria for whether a project belongs though but more of a pre-requisite to finally moving in.

[graingert]

I think #42 is advocating that new projects be using main as their default branch before being included. I don't think that counts as criteria for whether a project belongs though but more of a pre-requisite to finally moving in.

Agreed

[timothycrosley]

In addition to requirements for projects that join (along the same line as #42), would it make sense for PyCQA to have some general recommendations and defaults?

Background: #42 encouraged me to do some soul searching about isort's own branching strategy. Which has been following an adjusted git-flow workflow, with develop being the main branch and master being reserved for releases. I had thought at the time I chose this branching strategy that it was a good idea and was fairly typical. However, doing a quick survey of other projects on PyCQA, I'm now certain isort is the only project doing this, and in retrospect, I feel I've only gotten trouble from it. Would it make sense, as an example, for PyCQA to recommend a trunk-based branching strategy for projects within the organization?

If so, and if it's helpful, as I look (or am told!) about ways that isort is inconsistent with other PyCQA projects, I can build up a catalog of these observations as candidates for PyCQA's new project suggested defaults, and then submit a PR here.

[sigmavirus24]

In addition to requirements for projects that join (along the same line as #42), would it make sense for PyCQA to have some general recommendations and defaults?

So this gets back to some of my thoughts I think I may have expressed in #25. Namely, there's a continuous line along which "organizations" exist. On the one end, there's chaos, no standardization, and folks are loosely organized. That's close to where we are today I think. On the other end, there's lots of bureaucracy, possibly a foundation with a bunch of people getting paid to make technical direction decisions for enterprises.

I created the PyCQA partly as a joke, partly because I needed to re-home Flake8 but didn't want it to be "my" project (or exist under my username to be more accurate), partly because I wanted to see a community form around the tools in the community.

I've invited people and tried to make the organization fairly open and I think we've largely achieved that. I haven't had the appetite to try to create and impose standards on others and no one's really had the appetite to do that yet either it seems. I think that's served us well. The one thing we all have is a code of conduct.

To be super-clear: Much of the lack of standardization/rules/etc. is due (probably?) to my just not being passionate enough to spend my time on it. If there were a consensus of people demanding it, I'd be open to it, but I wouldn't personally want to manage it. It's kind of like how I don't like that I'm basically the person that subjectively says "Yes you can enter the organization" mostly because I don't want a bunch of cruft hanging around and I haven't established a rule of "If you abandon your project, I will archive it (or add people to it that seem to want to maintain it)." and thus looking for active projects with maintainers that are popular has seemed to work out reasonably well for not having to think about that.

I don't like dictatorships (benevolent or otherwise), and committees don't work in F/OSS either. In short, while I've offered and given access to different people, it always seems to fall back to me (whether that's getting folks invited and set-up here, or moderating code-quality@python.org, etc.).

The (formerly known as) OpenStack Foundation seemed like a bureaucratic nightmare and pre-big tent was ridiculously hard to get projects into, and post-big tent way too easy to get projects into.

---

To summarize:

• I don't like the current state of affairs. It's too much of a dictatorship
• I don't like the organizational nonsense I've seen elsewhere or the bureaucracy
• I'm not interested in forcing people to do things a certain way
• If anything's to be done, I'd love to see it be bought into by people in most of the projects (trust me, I know consensus doesn't work either)
• I don't think folks should be preventing others from making the right choices for their projects (this happened in OpenStack and was frankly ridiculous)
• I don't have ideas or the energy to figure out the right thing to do here. I'm happy to cede that to people more interested in this.

[sambhav]

I think in the long term even if we don't end up with a consistent set of standards or something similar, I would like the project maintainers under this umbrella to at least have some common place to meet and discuss ongoing issues (which is better than GH issues or the mailing list, I know we have an irc channel but that seems mostly abandoned), future plans and see if we can collaborate with each other on common pain points like config management, CLI options, packaging, multi platform support/testing strategies or cross project plugins (especially applicable to flake8 I guess). These are the kind of topics where I would love inputs from other people in the pycqa umbrella. Also IMHO, I think a lot of people use these tools in tandem and it would be amazing if we could figure out a way to offer a nice and consistent experience for tools that do go well together.

Edit - #11 seems related.

[sigmavirus24]

@samj1912 yeah, I've updated that. I think GitHub teams discussions could be an easy starting point here, but I don't know what folks think of that. There are also more options now (I think) than in 2016

[sigmavirus24]

Perhaps I should be clear about what my goals are in having this issue here:

• I would like to, one day, be able to nope right out of F/OSS altogether and never feel like I have to find someone to replace me. And I'd like to work towards that here.
• I'd like not to burden one person, with the responsibilities of this organization because that's just passing burnout on to the next person (although, frankly, the PyCQA was always relatively close to 0 contribution to my having burnt out). In other words, I'd like to make this more of a thing a group can collaborate on
• I'd like to not have one subjective set of criteria morph when passing on to the next person so I'd like a fairly clear way of making a decision (a checklist, or something)

[sigmavirus24]

A perfect example is https://mail.python.org/archives/list/code-quality@python.org/thread/IKMO5EPFCRCZM4VMWY2FO3LVSIQBZEW6/ this is a brand new project that's very young and seems like it'll be abandoned or perhaps competes with another wider used tool

[sigmavirus24]

I should also say that my philosophy when it comes to software is "No is temporary. Yes is forever" and I feel that's applicable here too. If I say yes and this project withers as I expect it too, then what do we do with it? Archive it? Transfer it back to the creator who probably won't want it? Meanwhile if I say No and this thrives and needs an org home, we can always accept it then and help the creator out.