>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> The interested students will likely also be at least casual Emacs users.
>>> So, some degree of familiarity is expected.
>>
>> User-level familiarity doesn't help in these matters, IME.
>
>>> Other than that, how is Emacs dramatically different from working with
>>> any other large codebase?
>>
>> In a nutshell, Emacs is much larger than most other projects, and its
>> features are much less localized than those of other large projects.
>
>But not every feature, right? Some parts are easier to hack than others.
>I imagine that many Elisp parts are somewhat easier compared to C code.
>
>>> What is needed is a formulation of projects/features that are desired.
>>> Mentors do not have to be maintainers. Experienced Emacs contributors
>>> can be the mentors (also, mentoring a student can be a good addition to
>>> some types of CVs).
>>
>> We have etc/TODO which could be used as a source of ideas.
>
>Are there any specific todo items there that you view as more suitable
>for people with limited experience in Emacs codebase?

I am not sure if this is something, I hope you don't mind me asking, but could a
work to modularize Org, be an appropriate subject?

For example turn displaying pretty text (bold, italics etc), pretty links,
tables, dates, and perhaps some other stuff into, from Org-mode, independent,
minor modes that could be used in other parts of Emacs and more independently of
Org mode. I think both Org-mode and Hyperbole, and perhaps some other libraries
(button.el, help-mode, info), could use some minor mode that works with
links. For us users, it would mean less cruft loaded into Emacs, if those big
players could share some code.

I haven't done much research on this, just something I had in my head for a long
time.