Re: How you can help

[Sebastian Rose <sebastian_rose@gmx.de>]

Sebastian Rose wrote:
> Should we put a page on worg by this name (see subject of this
> thread)? We could show, how to turn on debugging, write a good bug
> report, link to good elisp tutorials and describe how to use the elisp
> debugger in emacs for simple debugging.
> 
> If no one stops me, I'll do it these days. As or me, a page like that
> would be helpfull. I'll be back for report - maybe one of the lisp
> freaks could add some details later on?



Hm - there is a link to the 'Feedback' section of the manual
(http://orgmode.org/org.html#Feedback) on
http://orgmode.org/worg/org-contribute.php but

  1. It's hard to find. One has find worg (http://orgmode.org/worg/),
     and then click 'How to contribute to Org?' to get to
     http://orgmode.org/worg/org-contribute.php where the link is.
     I think I wouldn't follow the link 'How to contribute to Org', if
     I was to report a bug (maybe it's my bad english, but I lots of
     people whos english is even worse).

  2. While the 'Feedback' section in the manual is as good as the rest
     of it, it's short and does, for good reasons, not provide more
     information, than absolutely needed.


Suggestions:

   1. on Worgs startpage (http://orgmode.org/worg/): add an extra section
      (as the FIRST one) 'How you can help'.

   2. Under that headline, put the link to the 'Feedback' section of the
      manual.

   3. Add more links to one or more pages for tips on debugging etc.

   4. Add subdirectory for those debugging tips. We could also add things
      like coding conventions, notes about the APIs in org etc. to that
      directory.



....Please comment...




   5. I also think of little packages for testing parts of org.

      Example XHTML-export:

      When the HTML-exporter didn't work lately, I set up a little
      directory or testing. On top of that tree I had an Org-file with
      [[elisp:]] links to click on, like
      [[elisp:(setq debug-on-error t)]]
      or [[elisp:(debug-on-entry 'org-export-org-to)]] and one for
      loading a setup.el in the same directory (primaryly to adjust
      org-publish-project-alist - in principle, everything could be
      setup in that file, but needed two different setups for these
      tests).

      Now I can just open that Org-file, click on two or three links
      and get a backtrace, if something is wrong. It's so simple to
      test the exporter this way, that it takes 30 seconds or even less
      (on failure :-)

      With simple trees like that (eventually downloadable as *.tar.bz2)
      one may test a module with all the little corner cases, which
      might not be in the Org-files the tester uses for his daily work
      and without risk.

      If we encounter a new corner case, we could just add it to the
      test packages Org-files and document it in the packages index.org
      (or README.org) to prevent a regression.

      When working on a module, one could programm against those tests.



Creating and maintaining those test packages is a simple thing to do.
All it requires is knowledge of USING org and just a tiny little extra.
Hence I suppose this work should be done by the community/worgers.

It will be much more fun to add tested patches (and more secure to
create one)!






Regards,

   Sebastian


> Carsten Dominik wrote:
>> Hi Org users,
>>
>> I need to get control over the time I spent on developing
>> Org-mode.  Recently, I have again worked too hard on it, spending
>> more time than I should, in order to get 6.9 and 6.10 out and to
>> seize the chance to get the best possible version into Emacs
>> 23.1.
>>
>> However, this is getting out of control, and I am now putting
>> myself a hard limit of 1 hour per day, clocked by Org-mode, which
>> will clearly cut in on my development speed and posting rate.
>>
>> Here is how you can help me to make the most of that one hour.
>>
>> 1. If you report a bug, please try to do as much work as you can
>>    yourself.  Before you send it, think if you have collected all
>>    the information you can.  There are great examples of good bug
>>    reports on the list already.  The best bug reports are, of
>>    course, those that are accompanied by a patch.
>>
>> 2. If you are reading the list and see bug reports, consider
>>    putting in 10 minutes, trying to reproduce this problem
>>    yourself, and maybe adding information that might be useful
>>    for me to track down that bug.  Again, this is already
>>    happening, I am only trying to encourage this type of
>>    behavior.
>>
>> 3. I have recently spent much time on fixing bugs in parts of Org
>>    that I did not write myself, so this is taking much more time
>>    than usually.  If you know Emacs Lisp, and I know there are a
>>    number of excellent Lisp programmers on this group, consider
>>    "adopting" one of the following subsystems.  By "adoption", I
>>    mean that you make it your mission to deeply understand this
>>    part of Org, so that *you* will be in the position to fix
>>    bugs, taking that off my shoulders.
>>
>>    - org-publish.el.  I think the biggest bugs are out now, but I
>>      am sure this system can be improved quite a bit.  If you are
>>      that Lisp programmer trying to take up this task, consider
>>      teaming up with Sebastian Rose who is a great guy, has quite
>>      some understanding of that system and good ideas about it,
>>      but just is not enough of a Lisp programmer to really take
>>      that on.
>>
>>    - org-export-latex.el.  This is a tough one because you need
>>      to know both LaTeX and Lisp.  And the code is complex, in
>>      part because Org-mode allows to write LaTeX is a relatively
>>      lazy way.  Bastien has done a great great job capturing this
>>      into an exporter.  However, there are still problems and
>>      bugs, some came up recently on the list.  And Bastien
>>      currently does not have the time to contribute consistently.
>>      As a result, I have started to fix some bugs, but this is
>>      really eating too much of my time.  This subsystem can also
>>      use feature additions, for example better handling of image
>>      insertion, maybe with captions.  I have ideas about this, so
>>      talk to me if you want to help out.
>>
>> 4. Try to answer as many messages on the mailing list as you can.
>>    I have been trying hard to make sure that each and every
>>    reasonable question on the list (and this is really the only
>>    kind we get in this amazing community) will be answered.
>>    Doing this still takes a significant fraction of my Org-mode
>>    development time.  I will clearly spend less time on this in
>>    the future, in this way also giving others more time to
>>    answer.  Again, there are already quite a few people who
>>    regularly *answer* questions, and all I am trying to do here
>>    is encouraging this activity.
>>
>> 5. Help developing the Org-mode FAQ by adding useful information
>>    to it yourself.  All you need to do is to get acces to Worg,
>>    which will help getting to know git in the process.  Worg is
>>    meant to be user edited, so please go wild and add information
>>    and links at will.
>>
>> Thanks to you all, for your understanding and help.
>>
>> - Carsten
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
> 
> 
> 
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>