How can a non-programmer help the project

wtrys said:
Hey all! I've been using FreeBSD for a while now, and I'd like to contribute to the project. However, I am not a programmer (at least not a good one, especially in C). Are there any ways I can help?
Click to expand...
The most obvious is "documentation".

But, that can happen at many different levels!

E.g., you can proofread documentation for spelling and grammatical errors (the author(s) may not be native english language speakers).

You can evaluate how clearly they are conveying information (the documentation is often written by someone who is already conversant with the tool so there are undoubtedly assumptions baked into the description).

You can "follow instructions" and see if they proves to be clear AND correct -- possibly uncovering errors in them or in the actual code/process.

You can double-check claims made in the documentation; does it REALLY work this way? What if I make a mistake in using it, how does it respond? Do the error messages convey USEFUL (to YOU!) meaning? Or, do you have to be an insider to make sense of it?

Remember, any time you are confused or uncertain, that is an indication of the NEED for additional documentation or for errors IN the documentation.

For example, the 14.1R installer asks for the machine's hostname. Should that be a fully qualified name? Will the installer choke if given one? Will it know to set the domain name FROM such a fully qualified name? Or, will you be tasked, elsewhere, with specifying that?

Even without "programming" knowledge, you can peek into select sources to get hints as to areas where the code may differ from the documentation. For example, when I build a "port", I check the way arguments are handled (the various options supported). I may find an option that is supported that is not documented. Or, the documenation may claim that an option defaults to "OFF" when the code suggests it is actually ON!

Simply pointing others at things that you discover is a worthwhile service.

[And, modest evangelism is always appreciated]
 
You can report problems you found, test fixes / upgrades and report back, provide patches to upgrade ports, fix something you can would help.
Doing what you can would be welcomed.

I'm not at all / no longer a good programmer, but varieties of my examples:
Simply reporting problems:
PR 260281

Providing additional data point and test provided patch:
PR 282335

Provide some analysis and tests:
PR 277021

Search and report new upstream for missingly deleted ports:
PR 276245

Allow unused but useful functionalities that upstream has:
PR 276165

Tests, tests, tests and tests:
PR 273291
PR 268652

Providing updates for ports with some fixes:
PR 282312

Update no longer applicable patches by others:
PR 207940
PR 90815

Send patch for forgotten-to-be-applied changes:
PR 182963

Sharing experiences and sharable scripts at bsd.cafe repo.

Of course, supporting newbies with lesser experiences/knowledges than you here would help, too.
 
I'm not a programmer, or even a coder and really not even a scripter--I mean I can do stuff that works for me but I'd be embarrassed to show it here, for example, but...
A lot of times you can pick up things--I remember, though the memory is hazy, finding something (years ago, when we mostly used ports) something weird in the postfix Makefile that could be fixed, I don't remember what, but I was able to make a patch (which is fairly easy) and send it to the maintainer. As has been said, documentation--for example, I saw something missing in the dwl window manager man page, and was able to patch it, just by using the dwm man page (the two window managers are VERY similar), and the FreeBSD maintainer added it before the developer did.

Another example--I'm sorry to be so vague but this one was awhile ago too--dmenu (for dwm) had a problem. Doing a bit of web searching showed that the later version had fixed the problem. I sent a quick email to the maintainer mentioning this and they updated it that day or the next day.

The point being, that even not being a coder, you can find small errors, and, perhaps because FreeBSD is relatively small compared to Linux, you can let the port's maintainer know and they will often answer you, and utilize what you send. Also, as has been said, examples for the man pages might be useful. For example, say a man page is hard for you to understand, you do a bit of web searching and find a very clarifying example, send it to the maintainer. Often, if you open the man page in vi you'll be able to see the format and create a patch, even without a lot of knowledge.

I have a dated page, actually done by Josh Glover, and not even html, it's text, so you'd have to download it if you trust me, https://www.scottro.net/qnd/qnd-diff-patch which covers how to create and appy a patch. It's not hard. You can try opening a manpage in vi and even play around with adding an example, then view your new page with man to see if it's done correctly.
 
Another thing non-developers like us can do is to upload hardware probing data on which you're running FreeBSD on. This is because FreeBSD community is relatively small and almost always lacking hardware data to see how FreeBSD recognizes them.

For hardwares your employer (companies, etc.) owns, you could be required to acquire permission of managements, though.

You can use sysutils/hw-probe for the purpose.

An example (old data of my personally owning ThinkPad P52) here.
 
There are also work groups and regular calls you can join to find matching/the best ways to contribute. Joining those really is a two way street: you can learn from the others and actively help by working on relevant activities for the groups (i.e. testing, documenting, speaking about your learnings and experiences).
There may be more...
 
T-Aoki said:
Another thing non-developers like us can do is to upload hardware probing data on which you're running FreeBSD on. This is because FreeBSD community is relatively small and almost always lacking hardware data to see how FreeBSD recognizes them.

For hardwares your employer (companies, etc.) owns, you could be required to acquire permission of managements, though.

You can use sysutils/hw-probe for the purpose.

An example (old data of my personally owning ThinkPad P52) here.
Click to expand...
Just did it! https://bsd-hardware.info/?probe=10ab9145d9
 
You must log in or register to reply here.
Back
Top