Hi Folks. I am interested in helping out with documentation and I'm looking for suggestions on where to start. Here are a couple of possibilities.
When I built the EFL docs form git, I got 5600+ warning messages, mostly of the "member foo in bar is not documented" variety. I would be happy to spend time cleaning up those and other Doxygen warning messages, lib by lib, so docs build clean. This will require that I ask individual developers when I can't figure out what "foo" does. I can read and write C, but it's not always obvious. It also will mean a bunch of non-code commits to EFL. If it's a bad idea to work on EFL docs, I could work on docs for something non-core in Apps or Modules. In a similar vein, i could team up with someone creating something new and help doc that. There was talk of an IDE recently that sounded interesting... Should I just pick one and start sending patches? I am open to guidance and suggestions. On a side note, there have been some recent suggestions for @-tags for commit messages. A @doc tag might be useful to identify pure doc changes (no code change), mostly so those that don't care can easily ignore them. -- Jeff Grimshaw ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
