[fdp] Updated Managing Contributor Lists

[jpb_jimby.name]

Summary

This entry includes some additions and corrections from work done with adding Hans Petter Selasky to the "In Memoriam" section.

The procedures for all lists have been updated. However, one question remains -

For some entries, such as changes to ~/doc/shared/contrib-corealumni.adoc, and ~/doc/website/content/en/administration.adoc, should those entries be managed by the admin teams? Is there a conflict with the other teams?

Test Plan

Linted with vale for this section only.

[jpb_jimby.name]

[fdp] Updated Managing Contributor Lists

[jpb_jimby.name]

Added Alexander Ziaee to the reviewer's list.

[ziaee]

documentation/content/en/books/fdp-primer/structure/_index.adoc

365

Are changes also required for src/share/misc/comitters*?

[jpb_jimby.name]

documentation/content/en/books/fdp-primer/structure/_index.adoc

365

That's a good question. These are *.dot files, for use with graphviz. I'm not aware that they are actually used anywhere. And, from what I can tell, they have not been maintained very well over the years. Even rendered they are a chaotic mess.

It's worth a larger discussion with doc_eng as to whether these files are worth maintaining at all, or whether they should be retired.

[ziaee]

Okay, I was going to add them but they're cc'd already!

[dbaio]

documentation/content/en/books/fdp-primer/structure/_index.adoc

365

It would be nice to add this as well... If they are listed in src/share/misc/committers-[doc|src|ports].dot under 'Current Committers', move them to the Alumni section and add the final date.

These files hold historical information about mentors and mentees. While they may be a bit outdated, they are still important. We often use them as a starting point for new committers to make their first contributions. It's a good way for them to get familiar with the project's git repositories... these files act like guinea pigs in the process.

[jpb_jimby.name]

Added change info for src/share/misc/commiters-doc/ports/src as requested.

[dbaio]

Minor things to fix before committing.
I've already given my review/approval to speed up the commit in case @ziaee wants to proceed with this review.

documentation/content/en/books/fdp-primer/structure/_index.adoc

270

https://ports.freebsd.org/cgi/ports.cgi?query=graphviz&stype=all&sektion=all could be package:graphics/graphviz[], but either way, it is not very effective. We need a ports portal similar to FreshPorts. =/
Let it as you prefer.

274

same, could be package:graphics/graphviz[]

275

why not, dot here?

355

If they are a current member of one or more...

[ziaee]

documentation/content/en/books/fdp-primer/structure/_index.adoc

270

I use/prefer package:graphics/graphviz[].

I know I'm in the minority with this one, but actually I really like the interface. Like many other things in FreeBSD, it's a direct line to the surprisingly clean manual transmission. This provides the best pipeline of users to developers, and makes FreeBSD the premier platform for creating appliances. I, for one, hope we continue to expose and refine the manual transmission, but of course I support the community whichever direction rough consensus takes us.

[jpb_jimby.name]

Updated as requested. New differential arriving shortly.

documentation/content/en/books/fdp-primer/structure/_index.adoc

275

There are three uses of the word "dot" in very close proximity. I'm trying to clearly differentiate between the manual page dot(1) , the program named "dot", and the format of the input file ".dot". The verbiage ".dot format" is actually used in the file.

The different uses of the same word needed some clarity.

[dbaio]

documentation/content/en/books/fdp-primer/structure/_index.adoc

270

I'm not sure if I followed. Do you mean you prefer cgit or the ports.cgi interface?

https://ports.freebsd.org/cgi/ports.cgi?query=graphviz&stype=all&sektion=all --> goes to ports.cgi.

The link package:devel/git[] --> https://cgit.freebsd.org/ports/tree/graphics/graphviz

Using the package: macro is easy, but it redirects users to cgit.

IMHO, both interfaces are currently not user-friendly.
If ports.cgi had a button to show or hide the dependencies, it would be way cleaner/better in my POV.

[ziaee]

I prefer cgit. I think a clean interface to the raw mechanism is most friendly to the audience we've historically been most successful with.

[carlavilla]

Approved

[carlavilla]

Done, I made a couple tweaks, thanks!