I am and will continue to do what I can to support you, but as the potential second dev member on the restart attempt, you’re starting at a bad time, with a health outage of the other dev, plus a bad release.
We will see how gpatel-fr progresses. Weeks should be enough to see improvement on both fronts.
If administration refers to highest level jobs, I think there have been roles or hierarchy a long time, and this seems reasonable on the surface, but causes single point of potential failure (truck factor) or wait.
I would prefer to have a more specific talk about labels, if that is a big focus. Even though Triage role is able to change them, I’ve done no big change, and individual uses have been mostly on issues worked.
On closing issues, gpatel-fr has already asked on a now-244-post topic begun in 2018 then brought back from the dead by a similar new issue that was tacked on, that idle topics be closed to stop that…
I talked about issues there and also with you, and I expect your review will find many non-helpful ones. Unfortunately GitHub (or at least our setup) allows continued posts to closed issues, and people do so. The issue template does ask “I have searched open and closed issues for duplicates.” but can change. There might not be a pull request template, but I think sometimes those also help set the expectations. Working on defining those in a briefly explainable way would also help produce a useful longer version.
Typically here (and this is typical in open source as I understand it – correct me if I’m wrong), there is a progression of role based on things like time and merit, which makes it different than companies where there is extensive pre-vetting. I certainly wasn’t invited instantly, and I declined Write because it didn’t seem necessary, while adding risks of newbie me. My attitude was probably influenced by a co-worker who on day one at a previous company had deleted their source repo by accident. Don’t let that be me. Looking way above my level at the GitHub role summary, it looks like only Admin can make huge mess.
You have seen a lot, and the upside of lack of process here is that you can play a large role in shaping. After that, publish it. There is plenty of good advice on helping start people. Duplicati could do far more, subject to volunteers, as always. Some things are harder than others. A big design doc may be difficult, however there’s also the point of view that the code exists, and is going to be current as things change.
I’ve posted references to crumbs of info that I know about, when people ask. I can certainly do it again, however better would be if someone could make a presentable version and get it reviewed and posted, which requires volunteers with different skills. If I point to my guess, you’d certainly find out if I guessed right or wrong after you look at the code awhile, sort of iterate until “OK”, and next person is a next test.
I’m pretty open to trying some other ways. As you note, and I agree, we’re a bit loose, but not totally so. Focus is usually on non-performance bug fixes. This topic is an example. Goal was set, goal was done, ignoring the fact that macOS didn’t quite work as expected despite some pre-Canary testing attempts…
Performance metrics would be very hardware dependent, but this points to the lack of Duplicati facilities that aren’t either personally owned or maybe rented from a cloud and possibly shared with some others. Duplicati isn’t rich enough to pay developers, but I’d like to see if money can be usefully used somehow.
Any shared project infrastructure raises question of administration. Personal is easy but not very flexible. FWIW I’m sometimes using the PC I’m typing on for performance tests or expected hardships like killing Duplicati at random times which can break backup, and some issues are filed that I’d prefer to see fixed.
Having a dedicated system which at various times is measuring, challenging using expected challenges, or some other worthwhile task might be nice. I do have a PC to offer, semi-retired because it’s very slow.
Metrics also raise the question (which might be good) of whether small incremental changes can nudge their way to the ultimate goal (whatever that is…) or if goals will push incremental higher until impossible without the extensive design change one was hoping to avoid. But at least the devs will get experienced.
I guess that’s the “Specific” “Measureable” and “Achievable”. “Relevant” is up for debate but could likely be inferred from looking in forum and issues to see where it hurts and how badly. Maybe also apply our own judgments based on things we see coming, e.g. .NET Framework works now, but not in far futures.
Your actual-performance examples remind me of a thought I had on how to create a metric for “Stable”. Bug counts can be worked down by combining bugs or tweaking priorities, however there’s also results seen from the user base in terms of support requests, maybe categorized. Rough metric isn’t very hard, and is kind of what’s done by polling people to see if Canary seems no worse than usual, so goes Beta.
Although time may bring gpatel-fr back, what more can I do to help there, while attempting to fill in?
Resources aren’t something I can solve, although in the long run I’ve laid out some options to improve getting people started. I’m also trying to bootstrap that with a start from me, then you continue booting.
Although you want some better process for the people, and I tend to agree, you don’t strike me as one favoring mega-corp levels of process either, so it will take some guessing as to what the right level is…
Thanks for your interest and ideas. I’m sort of winging it here, but I think you could get some of them in. Hopefully someone else will shoot me a PM or something if I’m getting too far from what they would do.