Unrelated question, but one I think relates to how the clj-commons GitHub org is configured. I wish to protect my main branch from direct pushes, and only allow changes to come in via pull request. This is configured in a repository’s Settings > Branches > Branch protection rules > <branch name> edit > Protect matching branches section. For non-org repositories, one can check the “Require a pull request before merging” setting, uncheck the “Require approvals” setting, and you’re done. For clj-commons repositories, the “Require approvals” checkbox is checked and greyed out:

Unfortunately, this checkbox also makes it such that a PR author cannot approve their own PR, so leaving it checked results in an unworkable situation (I can’t promote anything to my main branch without conscripting help from a co-maintainer… …who doesn’t currently exist).

For now I’ll turn “Require a pull request before merging” off, but is this something an org admin can check at the org level?

@deactivateduser10790 Perhaps if you want CLA Assistant integration and more control over PRs etc, you should move your libraries back out of clj-commons? Most of your libraries don't qualify for clj-commons according to the docs about how/why libraries get adopted.

So why were they added, back in the day? :thinking_face:

I didn’t ask for them to be included in clj-commons (though I also wasn’t opposed to it)…

https://github.com/clj-commons/meta#entry-criteria -- I think they should not have been included based on those entry criteria, but I don't know the history of how they got transferred in.

That document was added 2-3 years after my projects were transferred.

There may have been an earlier version elsewhere of course, though I don’t recall ever seeing such a thing at that time.

Anyway, if you’re saying clj-commons doesn’t want them, I’m happy to work with you (collective) to transfer them back.

FYI Unfurl was transferred into the org in spring 2019. Those entry criteria were added to the meta readme a month later. I didn't check your other projects. But you seem to have been actively maintaining them all along and they're definitely niche libraries so I don't think it makes sense for you to be bound by the organization's processes and "rules". You'd have more control over them under your own username or some org of your own... Happy to discuss with @slipset and @danielcompton

(or at least that's what Unfurl's commit history indicates)

I don't believe that history is accurate, as I left the job that I'd developed it at in July of 2018, and I know the transfer happened before I left (and also the transfer of my other projects that @slipset expressed an interest in - we did them all at once). Regardless, I understand the mission and scope of clj-commons has been refined since then, and as you say my projects may no longer qualify under the new criteria, so I'm on board with your proposal to transfer them back. Let me know what (if anything) I need to do to help accomplish that.

I don’t think you need to do much more than transfer the projects to your own github? LMK if there is some permission stuff needed.

Out of curiosity, and I agree it’s a bit strange for clj-commons, but should cljs-rewrite be archnived? @lee @borkdude

Yeah @slipset I think rewrite-cljs is a historical artifact that rewrite-clj v1 has replaced. So I think it makes sense to archive it.

Just looking at the pinned repos under clj-commons and I notice that it is almost in star order: meta is first which makes sense but then it's in star order, except seesaw and rewrite-clj are missing. I can sort of understand seesaw not being promoted as heavily as aleph/`manifold`, but rewrite-clj now has more stars than pomegranate. It was this little exchange about cljs-rewrite than made me notice 🙂

There's https://github.blog/changelog/2021-09-14-readmes-for-organization-profiles/. Might be of interest for clj-commons. We are using it over at https://github.com/clj-easy.

I agree with what @lee said about rewrite-cljs