However, the earlier comment applies here too. Until one develops the ability to write clear & concise reports on the difficulties encountered, the port developers are not going to have patience in dealing with ambiguous & incomplete reports. They don't have the time to coddle.

You could start by browsing one of the ports@ mailing list archives, and then subscribing to the list. You will learn how communication between ports developers and testers takes place .... without having to commit to any direct participation; you can do this without ever posting.

Personally, my first experience as an OpenBSD tester was after posting an informal bug report to misc@. I ended up communicating with a developer directly, back and forth for several weeks. He worked up the patches for my hardware, I sent reports back, until the problem was resolved and his final patches were committed.

You could start by browsing one of the ports@ mailing list archives, and then subscribing to the list.

I wholeheartedly agree that familiarizing yourself with the appropriate lists is one of the right steps to take if ports testing is a goal. http://marc.info/ is one such archive site. References to others can be found on the mailing list page:

It should be mentioned that the role of porting third-party software to OpenBSD is:

to ensure that the application's basic functionality is preserved. Finding bugs in the application is good, but it is not the responsibility of the porter to fix all bugs; bugs may be due to OpenBSD-specific reasons or introduced by the OpenBSD porter. These should be fixed. However, deeper bugs may exist in in the application which are exhibited on other operating systems as well. It is better to pass these bug reports back to the parent project/developer for them to fix in the original code base. The point here is that the ported application should generally work in the same fashion as it does on other operating systems.

If testing can be made on alternate platforms (ie. macppc, sparc64, etc.), this may reveal additional flaws in design and/or implementation. It would be good to report these to whoever created the port, however, note that the decision may be to simply mark the port as broken on non-i386 platforms if the code base was written too specifically for i386. These errors should also be passed back to the parent project, however it is their decision as to whether they want to support more exotic architectures.