Mitar wrote: > So, what about this? You have a potential developer wanting to join in > and develop a new feature. Maybe even help with other stuff. But who > is afraid that if he even makes a patch it will stay in the ticket for > next 5 years.
Sadly, this is valid criticism. > So I would like to discuss things in advance, so that if > I spend time working on that I would not do in vain. I would only like > to assume that if the code will be of good quality, will not break > anything, will adhere to coding principles, will do what we discuss it > should do, ...., that it will be added to codebase, preferably for or > even before 0.13. You have chosen the best possible approach. > - make a settings option which would enable html5 doctype on all > current xhtml output > - if this settings option is in effect and (currently) the request is > coming from a known (configurable) browser which support html5 doctype > is changed We have been avoiding conditional rendering based on the browser type up to now, and preferring to generate output that works on all browsers. How do browsers that don't support HTML5 react if they have to parse HTML5? (Or that particular subset of HTML5 that you need for multi-attachment processing). > I would also implement preprocess interface, where plugins could deny > attachment, preprocess it in some way, maybe even more "replace or not > replace" behavior to it, like I described in previous e-mails. I would prefer keeping multi-attachment and attachment preprocessing separate, at least for now. This should make it easier to review. > Is this a valid proposal? Is it something Trac developers could agree > on that it would be useful to or at least that they would not mind it > be included in the core codebase for those of us who would find it > more then useful. I would like to suggest the following incremental way forward, to allow experimenting while at the same time avoiding "lost" work: - Fork our repository on BitBucket or Github - Implement only the UI part of multi-attachment, without the associated processing. If switching to HTML5 rendering is necessary, implement that, but unconditionally (i.e. for all browsers). If using jQuery and keeping XHTML is possible, this would be preferred. This should require a minimum amount of work on your side, and allow us to get a feeling of what the UI will look like and how it will be implemented in practice. Also, your changes should be fairly easy to review. The post-processing should be a separate proposal, and could best be started by creating a page below TracDev/Proposals, showing one or more use cases, and describing the new / changed interface(s). > So, you have one possible long-term contributor who really likes the > project and would like to join in the active development, but would > like some assurance that time and energy spend on the project would > not go in vain (of course I understand that you do not know me so it > is natural that those assurances would be conditioned by quality of my > results and similar). It just the feeling a person gets from the > tickets, that even if I will do my job properly it will collect dust. Again, this is a perfectly valid feeling, given our track record. I cannot make a promise, but I'll do my best to review your work and give you feedback. -- Remy
signature.asc
Description: OpenPGP digital signature
