The browser being able to do more in the past is perfectly normal considering it had to do less. HTML5/CSS3/JS evolved quite a bit in recent years and the web developers tend to use the new features. So years ago it was easier for the browser to render various things. It certainly feels like maintaining a web browser nowadays requires more people to actively work on it, to keep it up with the latest technologies.
I don’t need handholding. I just don’t like to be alone in a project, because I prefer collaboration, sharing ideas, and sometimes even challenges on how to do something better. Because being productive is not a goal in itself. I like to get involved so I can learn something new, to improve myself, and to have fun while at it.
For me in particular? I don’t expect anything. I just told you what works for me, and what didn’t - in this case.
And I didn’t even imply I’d expect to be managed. Not only that would be a waste of time for the PM, but it would also take the fun out of doing what the developers enjoys (and knows) best. One of the best points of an open source project is that it allows people to become self-reliant enough to pull through. But that doesn’t exclude collaboration on the same project, provided that there are more developers available for it. And that’s why people who prefer collaboration (like me) would join Haiku if they would be better handled when they contribute.
I’m sure it is for those who know how everything is structured, after years of involvement in the project, but it’s not the same for those new to it.
On Infrastructure Maintenance you have Project - Technology - Link. What about a new column? DEV could offer links to the places where the actual code is managed, so the developers can reach it with a single click and see how they can help. No need to waste any time asking such a trivial thing as where’s the code.
In my case, if I’d like to improve the User guide translator (PHP), I click that link, read those 3 sentences and find nothing about how I could help with “Reworking the user guide translator to use a modern framework” - as stated lower in the Infrastructure Maintenance section.
After clicking the link to the infrastructure on GitHub, I ended up in a repository what is missing a proper intro for people unfamiliar to Docker (I’m one of them). How do people find out where’s some app in the infrastructure? After checking “tools” and “data”, because it made more sense than “docker” - which could’ve had docker-related stuff, not projects -, I found out that in /docker/userguide there’s a Dockerfile and a Readme.md with a link to the actual place of the userguide-translator.
Ok, I found it. What next? The project doesn’t have an outline of what it’s supposed to accomplish (a few bullet-points of features), so you have to read the actual code. But you can’t tell much by how the code is structured, and the code is also not documented and you have to do a lot of guessing. You also don’t know what are your target PHP and PostgreSQL versions, which are important.
All of these could be presented in:
- the DEV link directly to userguide-translator project on GitHub;
- a readme file for the project.
So couple this with that unwelcoming feeling and maybe it will explain why some people don’t get involved. Especially those who know their way around the technologies involved would prefer a quick overview about what needs to be done, so they can easily assess if they can help without asking around and run into someone who didn’t have a great day - so to speak.
Online? I wouldn’t even like them, let alone expect such things. At work it’s different - everyone is on the same timetable, so no problem. But with people collaborating from various places in the world, when they have the spare time, that’s impractical and usually impossible. Any message board or mailing list is more appropriate for that.
When I was in the PHP-Fusion (international) crew we had people from over 20 countries pitching in on the various topics and areas that required attention. And the rare meetings were prepared in advance with the topic in the forum, so everyone can prepare in advance. The Skype meetings were usually 60 minutes long, in written form, mostly meant for quick votes and decisions based on clarifications that were better off in a chat than a forum. And those who couldn’t get on Skype at the set date and time, they left their input and votes in the forum. Everything else was based on coordination in the forum, which was quite effective.
Sure, if you take it as an excuse. But you can also take it as someone cares/needs that much about something that they wished they could add/fix it themselves, instead of doing unrelated work to free someone else to work on it. That particular thing might not be the what the “free” developers would even want to work on, due to other priorities and stuff.
So as much as we’d like, it’s not that simple. But things can be simpler if there’s some effort invested in making it easier for people to jump in. It surely doesn’t take much time nor much maintenance to add an extra column with links to the code, have a decent readme for each project and comments where the variable names don’t help at all. You can’t be self-reliant when you have no idea what to do with some code that doesn’t speak about the author’s intentions.