CZDanol
commented
2 weeks ago Hello, thank you for this issue. Those are very valid and nicely worded points. We were having quite some talks about this in the office recently actually, and we see this is our debt to the community that we feel the need to fix.
To complete the context, the discussion mentioned in the main post was happening here: https://github.com/prusa3d/Prusa-Firmware-Buddy/pull/3657#issuecomment-2336428749
Printer model
N/A, Documentation related
Describe the feature
Hi! I asked about this a bit in another issue, but I wanted to file a separate issue to continue this discussion and to make sure I'm causing any trouble and de-railing other issues. Tl;dr: I recently asked on Prusa's tracker about why a specific contribution had been deemed as something that needed to be worked on internally and not from an external contributor. To be totally clear: this was partly on me - a more thorough explanation of why had been mentioned earlier in the issue, but I didn't notice it when skimming through the discussion the first time. I also don't disagree or take issue with anything in the thread that prompted this, I think the reasons given were quite reasonable and I genuinely appreciate the response. Unlike the kernels I work on every day, a printer is a fire hazard - and not all of Prusa's ecosystem is open source, so some level of work certainly can't just happen externally for a plethora of various reasons. I should note too: I'm not speaking about anyone or for anyone in particular, I don't know the experience level or the feelings of any of the people in the issue that prompted this and certainly don't want to give any impression otherwise.
Anyway - after participating in that discussion, I looked through some of Prusa's contributor documentation (mainly here) and noticed that there's not actually any explicit expectations set for what sort of work might not be merge-able from an external contributor. And if there's one thing I've learned from working in FOSS as a day job for almost 10 years, it's that having expectations like that documented in an easy to find place is often times critical in helping encourage healthy discussion and active outside contribution. It can also shape people's overall perspective of a project and just how 'open' it is. Especially with contributors who are new to contributing to foss, it can be really discouraging to put a lot of time into a change - only to have it rejected for an unexpected reason. This can even happen if a reason is given afterwards, simply because at that point the work's already happened. But when these things are mentioned up front, people can taper their expectations and any kind of explanation or changes that are requested along those lines will tend to be much less discouraging. Speaking for myself at least, I definitely shy away from trying to spend time contributing on a project if it's not clear to me what the path for getting work merged actually looks like. I'd personally love to contribute to this firmware at some point when I have the time, as I've had a few ideas in my head for a while that may improve features like manual color changes. But it's hard to know how much of my time would be worth spending on those things when it's not clear if a contribution I were to make may be too involved to come from an external contributor like myself. And generally speaking: in the projects I work on for my day job I see these same kind of feelings very often. If anything, it's probably the single most common reason I've ever heard someone give me for why they weren't contributing to a project.
Expected functionality
Basically, I'd just like to ask if there could be some clearer expectations around what work can and can't be accepted from an external contributor in your contribution documentation. Guidelines like "work that involves changes requiring collaboration internally between Prusa's development teams across projects in our portfolio, such as GUI changes or changes related to PrusaConnect, may be difficult or unfeasible to merge from outside contributors for X and Y reason. It is recommended to ask about the feasibility of contributing a new feature externally first to avoid duplicating work" could help immensely here, and could also help reinforce Prusa's continued dedication to being open source in the 3D printing space to the masses. Especially since it reinforces to people following along that Prusa is very much interested in external contributions. At the moment, all of the documentation I can find on this repo is mainly around how a pull request should be formatted, code style, etc. I wasn't able to find anything clarifying along these lines.
I hope I didn't miss any documentation that goes more into detail about this anywhere! I definitely went looking for it before filing this issue :). Also, thank you prusa for the awesome printer (I have a modified MK4 in ASA that I use quite regularly) and the dedication to keeping things open source!