My previous employer used to plan "express checkout" weeks for developers. In between two larger projects, you'd get the chance to spend two weeks doing nothing other than picking low-hanging fruits off the bug-tracker tree.
It worked miracles, with minor-but-irritating bugs getting solved much faster, and with features for niche groups getting implemented as opposed to laying in wait for a bigger project it would thematically fit in.
Some devs even went out of their way to spend those two weeks on a single, irritating, deeply-rooted bug that nobody in their right mind would even want to fix.
I've been at a few orgs that do this kind of thing and most have found it valuable - but it is a double edged sword that will need to be managed. For the time not specifically allocated to "fixing bugs" or "removing tech debt" or whatever choice of phrasing there is, the rest of the time there is a (misguided) implicit pressure to permit quality to drop to make gains in delivery because "we have time allocated to fix things like this" - so the moral of this post is it is possibly more important to keep encouraging maintenance of quality throughout your team's cycle, and not let maintenance be ring fenced!
That works as long as there's no scoring system, no leaderboard and won't affect your performance review at the end of the year, or you'll just create another version of the Cobra Effect.
"The British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, enterprising people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped. When cobra breeders set their now-worthless snakes free, the wild cobra population further increased."
> Hacktoberfest is an October-long celebration to promote contributions to the free and open-source software communities. In 2020, participants were encouraged to submit four or more pull requests to any public free or open-source (FOS) repository, with a free "Hacktoberfest 2020" T-shirt for the first 75,000 participants to do so. The free T-shirts caused thousands of frivolous pull requests on FOS projects. A large volume of pull requests made by users amounted to counterproductive changes to code, including: changing project names from "My Project" to "My Awesome Project"; changing bullet points to dashes; and in some cases, even breaking working code
This is a ridiculous idea; if anything goes on to show how random hiring processes are imho. Check the contributions obviously but why flat out say "you joined a hackathon we don't like your kind here"?
This is a great idea and every company should set time aside for it. Not just a "oh we reserve X percent for issues", but a dedicated, "nothing on the todo list" period.
I worked at a place once where my favorite time was at the end of the year; most people were off on vacation but they needed a skeleton crew in case of issues. This was when we did tons of small bugfixes, improvements and refactorings, and honestly that's the best part of the job IMO. Screw building features and adding customer value, just let me do janitorial jobs :D
I have a theory that if you did away with the "big projects" and just maintained a clean environment you would find that most of the big projects suddenly become "oh yeah, we could do that with a couple of scripts now"
It's amazing what we live with in tech debt and what a clean environment would enable.
I was on a team that did three week sprints separated by a one week “do whatever you want” while the manager and tech lead planned the next three week sprint. I lived for those weeks! It was great for fixing bugs, refactoring for the hell of it, or adding new internal features. I probably learned the most during those one weeks, because someone would inevitably refactor something and we would all learn from the approach. Sometimes we didn’t even commit the new code, but would steal successful patterns for future code.
Sometimes, we would “invent” something novel and truly impressive that would open doors to future features that were previously impossible.
We were involved in the planning, but the tech lead and manager were dealing with the details and priorities from stakeholders. So the last/first couple of days were usually us giving feedback on their plan. But it actually worked out quite well. We were a small team (4-5 of us total), so there was constant communication and no dictation, but someone had to order the cards around and keep things organized.
We do that after every sprint and it does work wonders. So 2 or 3 weeks sprint then a week of this, sprint again, a week on the list, which can also be features - we maintain some 40 internal projects and not all projects get (or need) a sprint.
I personally like it because the issues are more diverse and I get to pick. For example, my last task was something a colleague complained about in a reporting tool that was also bothering me and I also got to learn something new
God, I miss that show. I completely forgot about Tyrell, I was mostly thinking of actual UNIX greybeards disguised as banking CTOs I've met earlier in my career :)
He's the author of Gnus. The news/email reader. It's a little crazy but a huge piece of work. Related to this was http://gmane.io/ which is a mailing list to NNTP gateway (so that they can be read using Gnus).
He wrote the Gnus news reader. Many years ago I found a bug in it on a Friday morning, I searched around and found out how to report it to him, by the afternoon of the same day he had notified me of a work around!
Idea for famous billionaires: support FOSS software and bug squashing streaks like this.
It automatically ensues positive image and accelerates advancement of humanity in science and tech, especially for programs that are core to everyday life of developers, like editors.
I think you overestimate the positive image boon. The only people who would care about supporting free software are fairly techy, and they're likely either already Musk supporters or so anti Musk they'd only see the move in a cynical light.
You can see this with Microsoft. Most people have no idea that "Microsoft Loves Open Source" is a thing. A few people seem to think Microsoft deserve the benefit of the doubt, some view it from a purely pragmatic view, and some will never forget "embrace, extend, extinguish."
The practical benefits might end up worthwhile for them though.
I think a lot of people have had their feelings about MS improved by their OSS contributions (myself included, and I'm not even a dev).
Of course it's not a binary thing for most people of flipping from "MS bad!" to "MS good!", some already liked MS and like them even more, some still hate them, still say "why should I trust them given their history / given they're not 100% lovely even now", but still surely a bit less hate than if they were still acting as they did 20-30 years ago.
I've no idea if my gut feeling is more or less right than yours, Id imagine companies as big as MS do actually do research to see how things like this affect public perception (not just for end users/businesses but also for tech workers), but I'm not aware of any research being made public on the PR benefits (or lack thereof) from contributing to open source stuff.
I mean the big tech companies rely heavily on these tools; surely they have the money to pay people a full-time wage, without using it as leverage to steer projects in their own direction?
They owe it to the open source community; they built trillion-dollar companies on top of open source.
They don't "owe" anything to "open source community". The licenses under which the software was made available more or less states that.
There are incentives to open source platforms so that they can build applications on top, support projects so that they can steer them etc. but they don't owe anything to the original developers.
I think the comment you're replying to is suggesting they morally owe it, the way you owe a thank you to someone who does something nice for you, not that they legally owe anything (example to demonstrate the type of "owe", not to suggest that a thank you is all that's owed). That's how I feel, at least.
I understand that. And that kind of debt makes sense in individuals. For a corporation (especially a large one), there is no single code of morality (either religious, social or anything else) that animates it except the bottom line. I submit that even "culture" and things which have a social angle are done specifically because they are profitable in the long term.
From that perspective, taking software that has been expressly allowed (in black and white) to be used with more or less no restrictions and without any need to give back is perfectly fine (and in some sense, even moral) as far the corporation and the code by which it functions is concerned. That's how I see it.
If the open source movement is interested in being sustainable etc., the licenses should bake in some kind of clause that incentivises the companies to pay back either monetarily or with effort. Of course, that would hurt their adoption so they choose not to but if they do that, they can't really complain when companies just take their work and use it many times without even an attribution.
Tag Mr Buffet. Don't tag anyone who will preside over the project as their own creation and will ultimately destroy any community momentum by turning it their own ego project that will destabilise the somewhat quiet community. We need funding, not more zealots
I find it inspiring to see how a interpreter that outlives me has such passionate and skilled contributors keeping it alive or rather, rejuvenating it with new life. Also impressed by the notion that someone could obtain such a strong command of, what I would consider, a somewhat "intimidating" codebase to own.
Happy Emacs user here and excited/grateful to see how well the ecosystem is currently doing.
Emacs bugs I've reported can vary from "I'd like this behaviour" to "something ain't right here" to "docs are borked on <subject>". Emacs is so stable there's not many crashing bugs to report.
Emacs devs are great btw, tolerant of occasional n00bishness and very responsive.
hmmm. I'm a regular emacs user w/ Doom configuration on top of emacs. I love emacs and I use it exclusively, however it does crash sometimes for me. It's enough to notice, but not enough for me to care.
As a fellow doom user, Emacs became lot more stable (and faster) after disabling bunch of default doom packages and modules. In its default config, doom really is intended for use on semi-modern processors with SSDs.That fancy modeline et al come at a cost.
emacs really is just an interpreter for emacs lisp. it does whatever you program it to do. it happens to come pre-programmed as a text editor from the "factory".
The beauty of emacs is how easy it is to modify it. Lisp is the easiest syntax to learn, emacs hides nothing from the user, and the user can override or add whatever they wish. It really is a proper example of free and open software. To add to this, it's all very well documented, and everything you need to develop (for) emacs is in emacs itself.
Why would you want an image-manipulation feature in a text editor (unless you were a developer who thought that it'd be a fun thing to work on)? That sounds like bloat of the worst kind...
Emacs is more of a Lisp interpreter with a text editor front-end interface. That said, being able to work with images can be useful. For example, while documenting the workflow of a GUI application it can be useful to open some screenshots and highlight relevant sections.
While it is true that dedicated applications are usually more capable and convenient for specialised tasks, having tools integrated together like in Emacs also has its strengths (e.g. it can allow for heavy scripting of a workflow).
I used to build my own emacs, but after being annoyed with it breaking after each upgrade on unstable, I use the emacs-snapshot repo on http://emacs.secretsauce.net/ with bleeding edge packages for Debian sid.
It worked miracles, with minor-but-irritating bugs getting solved much faster, and with features for niche groups getting implemented as opposed to laying in wait for a bigger project it would thematically fit in.
Some devs even went out of their way to spend those two weeks on a single, irritating, deeply-rooted bug that nobody in their right mind would even want to fix.