libera/#clim - IRC Chatlog
Search
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