emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Question Regarding Easier Issues To Help With
Date: Mon, 23 May 2022 16:36:43 +1000	[thread overview]
Message-ID: <87k0ac7nl6.fsf@gmail.com> (raw)
In-Reply-To: <ded4d69c-705d-4629-865a-55fde3b28599@www.fastmail.com>

"Samuel Banya" <sbanya@fastmail.com> writes:

> Hey there,
> So I took a look at the following link recently as I finally have had time again over the past couple of months since I've been
> dealing with a lot of personal family stuff, and got some time back again.
> Can anyone lead me in the right direction for some beginner tier issues to take a look at, as well as hand holding for any workflow
> on how to actually work on the related issue / source code accordingly:
> https://updates.orgmode.org/#help
> I ask because I'm a bit of an Elisp newbie. I'm assuming the first step is to try to reproduce the bug given the user's info, and then
> attempt to look at the codebase to see what might be causing it?

Hi Sam,

my recommendation would be to focus on the last part of what you
outlined i.e. recipe to reproduce a bug. 

This is often the most time consuming part for the core maintainers.
Given the size of org mode and the number of add on packages, as well as
the flexible configuration of org, it can be very challenging and time
consuming to get a minimal recipe which can reproduce an issue. 

Once an issue can be reliably reproduced, it typically takes little time
for a fix to be identified. 

Focusing on how to define a minimal reproducible case is also a useful
way to get familiar with org mode and the code structure. It can also
help develop elisp skills. 

Therefore, my suggestion would be to select some reported issues which
have not been confirmed or which don't have a clear, concise and minimal
recipe to reproduce and try to both confirm the issue and provide a
minimal recipe. I believe this would be a huge benefit for the core
maintainers. I also suspect that in many cases, once you do have a
minimal recipe to reproduce an issue, you will also see possible ways to
resolve the issue. When you do, you can report both the recipe and your
suggested solution/patch. The more experienced maintainers will quickly
be able to assess your recipe and proposed solution and provide feedback
for further improvements to your patch or perhaps guidance on how to
narrow things down further. 

  reply	other threads:[~2022-05-23  6:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23  4:53 Question Regarding Easier Issues To Help With Samuel Banya
2022-05-23  6:36 ` Tim Cross [this message]
2022-05-23  9:03 ` Ihor Radchenko
2022-05-25  0:58   ` Samuel Banya
2022-05-25  1:26     ` Ihor Radchenko
2022-05-25 14:04       ` Samuel Banya
2022-05-25 14:46         ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0ac7nl6.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).