libera/#clim - IRC Chatlog
Search
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.
9:04:09
lukego
helpers (lieutenants) can engage with the project with a reasonable learning curve. their job is to take responsibility for a PR and help the author get it into shape and clearly tell them what's needed to get it merged onto that helper's branch. then once they have a collection of changes they are happy with they can PR that to the head maintainer who might ask them to make changes or reject some changes that weren't actually good
9:05:03
lukego
contributors then are always dealing with exactly one person - a helper - who is responsible for telling them what is needed for *them* to accept the change and take responsibility for sending it to the head maintainer (who might always bounce it back)
9:05:35
lukego
so anyway it's scalable and doesn't put too much work on any one person. but like many scalable systems it has kind of high constant factors that might be overkill with bureaucracy in some contexts so I dunno if it would work for e.g. mcclim
9:06:35
beach
Yeah, for now there are probably not enough contributors for such an organization, but it's something to consider if things really take off.
9:08:41
lukego
maybe even at this point though it would be interesting to have a bit of clarity about what the "upstreaming process" would look like though. for example CLIME is basically working - for a narrow feature subset - but I don't really feel confident about whether a real PR would be welcome. and likewise I'm interested in the 'dot' contribution but I don't know if that has any chance of going upstream due to its dependency on an
9:09:40
lukego
so it could be that there appears to be less activity than there really is because people are holding back, not knowing how to get involved without burdening maintainers with too much extra work
9:12:29
lukego
(I'm certainly hearing a lot of comments about maintainers being overworked etc and I am sensitive to that, but it is a pity if that just means I won't contribute, because what I need is a way to contribute without burdening maintainers...)
9:16:10
lukego
but anyway this feels like a great step for me feeling free to open draft PRs and knowing that maintainers won't feel compelled to spend time reviewing them. I've opened one for CLIME and I'll probably create an integration branch with a few select features and open one for that too. Seems like a nice way to participate in a peer-to-peer way
9:19:23
lukego
it is a nice feeling of power being able to accept and merge changes myself, even if that is not going onto the main branch :)