libera/#clim - IRC Chatlog
Search
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 :)
9:42:12
jackdaniel
I will add my 2c to the discussion :) often there are people who are convinced that they know what will improve the process, but in fact they are just guessing or trying to apply experience read somewhere (or gained in other project) to domain where it is not applicable
9:42:44
jackdaniel
for small projects it is relatively rarer to see people jumping in with such rushed suggestions, but it still happens and it is important to know when to tell no
9:43:53
jackdaniel
example would be opening 3 or 4 new /official/ communication channels when the current ones are low volume -that would not be responsible because the community will spread too much and that would be actually coutnerproductive (as someone pointed out)
9:45:06
jackdaniel
that doesn't mean that non official groups shouldn't make their own communities. same goes for the organization: to have lieutenants you need a group of people (i.e more than 3) each having a deep understanding of the project and having time to do such duties (i.e being paid for that or having that much love for the project)
9:47:38
jackdaniel
and as the last remark: sometimes people want to contribute and that's great; but they are not interested in contributing in long term, so the time invested in teaching them is from the project maintanance perspective wasted. sometimes it is of course a necessary risk if we want to attract a long time contributors at all, but "more contributions" doesn't always mean "healthier project"
9:50:16
jackdaniel
I remember in one project a student joined and had some cool ideas for c++ integration (and automated tests). The pull request was big, it took a lot of time to review, but they have finished the project and never came back (and the work was not ready to be merged).
9:54:00
lukego
I kinda of understand where you're coming from but it sonuds like the next logical step would be to write "beware of the leopard" on the github repo and be done with it
9:55:04
lukego
but anyway, speaking of concentrating on fewer communication channels, I'll hop from IRC over to Github now and see how that goes
10:00:37
jackdaniel
I think you don't understand given that you conclude that this light handedly; these are genuine concerns emerging in any project accepting contributions. as noted, it does not mean to not accept new ideas, only to be assertive with people who /claim/ that they know better how to organize your work
10:07:54
scymtym
jackdaniel's ability to allocate his (partially paid) time is probably also at least somewhat constrained by the stated goals of the fundraiser [1] and the published roadmap [2] both of which focus on fixes, features and documentation [1] https://common-lisp.net/project/mcclim/posts/Crowdfunding-McCLIM-maintenance-and-development.html [2] https://common-lisp.net/project/mcclim/involve
11:33:50
jackdaniel
a random app for narrowing an issue: https://files.mastodon.social/media_attachments/files/106/397/537/134/692/239/original/8ff0c10eca7b0b61.mp4
11:56:15
contrapunctus
I've noticed that McCLIM's manual can be restructured a little so that it follows the Diataxis Framework (https://diataxis.fr/) and can serve people in different learning situations more effectively. For example, there's significant explanation in the tutorial which can be moved out into an Explanation section. Would the maintainers and the community like me to work on a PR for that?
12:22:35
jackdaniel
contrapunctus: sounds good. before you invest much time into that you may try to elaborate on the new structure (i.e focus on toc and share it)
12:24:25
jackdaniel
contrapunctus: thanks for the pr. I will squash it because it has 8 commits for two paragraphs change. in the future you may try to rebase it
13:03:51
jackdaniel
presentation mixins anyone?:) http://turtleware.eu/static/paste/26cfc528-stuff2.gif
13:24:40
alanz
ok, thanks. Ties up with my experience then. I just wondered if you were using some of the stuff lukego has been doing