Bastien <b...@gnu.org> writes:
> Hi Tim, > > Tim Cross <theophil...@gmail.com> writes: > >> I agree and am willing to help if I can. > > Great! Would you agree to be "officially" appointed to this role, > with Timothy? I put quotes on "officially": when moving toward the > new maintainance team, I'd like to list maintainers and their roles, > including the "contributor stewards". If you prefer not to publicly > appear but still work on this, that's perfectly okay too, of course. > Yes, but with some caveats. As may have already been picked up by some, I'm extremely conservative regarding the addition of new features and enhancements to org mode. I have considerable concern regarding both the performance and maintainability of the mode and worry about the increasing complexity in options, performance impact from increasingly complex font locking just to have more 'eye candy' at the cost of sluggish behaviour for large files and striking the right balance between the 'richness' of org file functionality and consistency in exporters or source block handling. I really would hate to see org mode end up like MS word with 90% of users only using 10% of the functionality with 90% unused functionality just becoming a burden to maintainers. For these reasons, I'm probably not the best person to assist with the review and guidance for patches aimed at adding/extending functionality. However, I would be happy to - Assist in trying to reproduce and confirm bugs - Assist in extracting additional information and providing guidance/clarification for bug reports - Assist with documentation - Provide some guidance on patches, particularly bug fixes. My time availability can vary greatly depending on work. Also, as a blind user, my ability to reproduce bugs can sometimes be hampered by the necessity of running Emacspeak in conjunction with org mode (they can sometimes interfere with each other). However, apart from that, more than happy to help where I can, so if your happy, sign me up! >> One thing I do think would be helpful, particularly for documentation on >> maintenance of org mode, would be a clear outline of project goals and >> philosophy. Some of this would be 'concrete' statements, such as the >> minimum supported Emacs version, size of contribution and requirements >> to sign FSF copyright assignment paperwork, inclusion of acceptance >> tests, documentation, maintenance of backwards compatibility, API >> stability etc. Other parts would be more 'fuzzy' guidelines, such as >> avoiding complexity and 'blow out' in options/arguments, balancing >> features and maintainability, what should become part of org core and >> what should be in contributions or a completely separate add on package >> and what guidelines are used in assessing extensions/enhancements for >> inclusion etc. >> >> It will be challenging to define this as there are a wide diversity of >> views and priorities amongst the community. However, I think it would be >> an overall benefit for both the community and on-going development of >> org mode. >> >> While I would be happy to help with this, I think the initial content at >> least needs to come from current key maintainers and if possible, some >> input from Carsten would be good. > > Fully agreed. Input from old timers will be precious, too. I will > work on this as we are transitioning to the new maintainance team. > > Also, I commit to achieve this transition by August, 1st. This may > seem a bit far away, but there is really no rush here, and I want to > ensure we have a smooth transition. All your efforts greatly appreciated. It is a lot of effort and herding cats often takes a lot longer then anticipated! -- Tim Cross
