libera/#clim - IRC Chatlog
Search
21:34:02
etimmons
Something that could help with discovery is asking for people to open Draft PRs on Github early on in the development of their feature
6:43:09
lukego
oh yeah draft PRs does sound like a great idea and if that's welcome on the main repo that sounds like an excellent solution.
6:46:46
lukego
That would also provide a place to write a blurb about what the branch is about, where it is at, etc, and a place for people to comment and discuss.
6:48:08
lukego
that's missing now e.g. if you open a random branch/fork like clime or dot then it just shows you the generic McCLIM README.md as the front page and by default doesn't allow opening issues for discussion (which would possibly be overkill anyway since one thread per feature branch is probably ample)
7:19:23
beach
I haven't followed the details of this discussion, nor have I thought about the details of all things suggested. But what I do know is that I often receive SICL-related requests formulated as "You should do A so that it will be easier for people to contribute B". But every time I work on a request by doing A is then never followed by any B from anybody else. So the net result is just more work for me.
8:04:09
lukego
yeah. thanks jackdaniel for making it clear that draft PRs are okay. I think that kills three birds with one stone. hackers can show what they are working on (eg. clime) in an up-to-date way, users can see what stuff is in the pipeline and how it is progressing, and potentially upstream maintainer can flag what work would be needed to make it acceptable to merge.
8:14:52
jackdaniel
to make it clear, I may occasionally look at drafts, but I'm not gping to review them until the author considers them as ready to merge
8:19:25
lukego
yeah, begning neglect seems like a valid strategy, i.e. just letting the community use them for collaboration
8:27:35
lukego
I made a draft PR for CLIME now: https://github.com/McCLIM/McCLIM/pull/1193. This is great because now there is a place to ask questions, make suggestions, track its status.
8:41:27
lukego
beach: it sounds like people are telling you something important, i.e. that they are having trouble engaging with the project as much as they would like to, but they are only guessing at what a solution might be.
8:46:10
lukego
I guess it's a bootstrapping problem for projects. it's always nice to come upon a project and see a working ecosystem with people reporting and fixing bugs, proposing and revising and merging changes, discussing and deciding on solutions, etc. then as a new entrant you can just join in and do the same that everyone else is doing. but it's easier said than done to end up in a situation like that and make it sustainable, I struggle anyw
8:47:23
lukego
can also be hard to know what kind of contributions maintainers actually want, and who they want those contributions from.
8:56:28
lukego
I've enjoyed using the Linux kernel model in recent years. then you have one "Linus" (e.g. jackdaniel) who is ultimately responsible for merging changes. But they are not reviewing individual PRs - that's too much work - instead they are reviewing collections of changes that their "lieutenants" have already approved and merged into their own integration branches.
8:59:58
lukego
editorial quality stays high because the head maintainer is making the final judgment and building a relationship with their lieutenants, explaining to them what is good and bad, so that they will have a shared understanding.