Mats, You are 100% correct. The doxygen is by far the easy part. I hope as a mentor, I can help smooth out some of the struggles a developer will have if they want to make improvements. In truth I am not 100% sure that I am the perfect person for the things I have volunteered to be a mentor for.
I have had a fair amount of success getting changes committed in the areas I have volunteered to help with. Some of that success is probably due to having an email associated with one of the major member companies. Some of the success is that I do things a little at a time. I almost never make a giant change. Maintainers like small changes they can understand quickly. We have had some amazingly good commits for build changes but they were huge changes that stalled mostly due to the size of the change. No one wants to be the maintainer that approved a change that inadvertently caused a huge number of problems. This is all new. I don't really know how much of a work load I have signed myself up for. I hope it is not too much. If I see things a lot I will update the wiki so I can point people there. George -----Original Message----- From: Mats Wichmann [mailto:m...@wichmann.us] Sent: Wednesday, May 3, 2017 12:54 PM To: Nash, George <george.nash at intel.com>; LaBrecque, Margaret <margaret.labrecque at intel.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] prelim list of areas where IoTivity needs new contributors On 05/03/2017 01:17 PM, Nash, George wrote: > Margaret, > > I split the documentation into two sections API documentation and Wiki > documentation. I am prepared to be a mentor for API related documentation but > I am not prepared to do the same for wiki related changes. > > If someone feels they would be willing to mentor with wiki related changes > please feel free to volunteer. > > To clarify if you are volunteering to be a mentor. You will help new or > experienced developers/volunteers to get involved with IoTivity if they want > to try and help in the area of interest. We can have multiple mentors for a > single section. If you feel you know enough about using Doxygen you could add > yourself as an additional Mentor for the Documentation API. FWIW, Doxygen is by far the Easy Part of this task. For those who are going to work on the API docs, understanding the API and its interaction with other APIs is key (in the sense that good docs will have cross-references, deprecation warnings will point to alternatives, etc.), as is figuring out what is really part of public apis and what is just documented but internal apis, how all the headers get included and thus interact with each other, and how to get changes merged when the maintainers of the affected areas who have to act on your gerrit requests are utterly slammed with things they see as much higher priority (usually rightly so). How you mentor the last part I'm not sure <speak="from experience"> but without some movement on the patch flow thing, it gets pretty frustrating pretty quickly </speak>
