Remy Blank wrote: > I've been following the latest discussions with much interest (in > particular the "Is Redmine a better Trac? What's gone wrong with > Trac?" thread). One of the recurring desires seem to be "getting the > community more (effectively) involved". > > Some ideas how to achieve that have been mentioned: Eli Carter asked > specifically for workflow/ticketing system lieutenants, and Christian > Boos gave a few generic entry points for helping out as well. > > I'm in the position of somebody who would like to help, and has some > spare time do do so. However, the advice of "tackling any problem of > intermediate size" is somewhat too generic for me. I would need some > guidance, to get started and along the way:
That's great Remy! Now let's get into some more detailed guidelines. > > - What are the currently "hot" topics for core developers? I would > rather invest time on an issue or feature that is perceived as being > important (desired, interesting, cool, etc.) than any old issue. This > would also lower the risk that a contribution would be left out > because other things are more important at some point. Well, the custom query module is your friend... you have many ways to figure out by yourself what are the tickets that are both important (usually priority set to high or highest) and related to your areas of interest (by filtering on the component or adding a few keywords). A few wiki pages can help as well: - http://trac.edgewall.org/wiki/HowToContribute explains the basics of contributing and has three queries, for helpwanted tickets, review ones and documentation tasks - http://trac.edgewall.org/wiki/TracDev/ToDo lists the hot-topics tickets, or the stuff about to be done - I've been using it as a way to inform others what I was about to do. Other developers are of course welcomed to use that page a bit more ;-) - last but not least, there is http://trac.edgewall.org/wiki/TracTicketTriage which in addition to providing guidelines for modifying the tickets also gives an overview of the tickets by *keywords*, which are used quite a bit on t.e.o as an additional way to structure the tickets Also, we should have less populated milestones, as it helps to get the focus on the more important or urgent issues. That's what I did for 0.11.1, by moving first all the previously assigned tickets to 0.11.2, so that we have a better visibility about what should go in the next release and what is simply scheduled for a given development line. I think we could eventually do the same for 0.12, first moving everything to 0.13, then selectively reschedule a few for 0.12. > - Once a desired work topic has been found, I would need some help > for defining the general direction for a solution. It would not be > very efficient to just run head down into some direction, only to get > told later that it wasn't adequate. Sometimes the ticket already contains some guidance, but if not, it's always possible to propose a solution (eventually with an initial patch to make the proposal more concrete) and ask for feedback, in the ticket itself. If there's no feedback there after a while, feel free to bug people here on Trac-dev about it. > - What would be the workflow for contributions by non-core > developers? Would I send patches against trunk or a branch, and have > them reviewed? Should the patches be reviewed by one core developer (a > tutor) or should the patches be reviewed on trac-dev? Or should I use > an externally-accessible DVCS (I'm currently using Mercurial)? The workflow for core developers and non-core developers shouldn't be necessarily different. Discussion and peer review should be a general rule that most core developers try to follow. But obviously the patch needs at some point to be committed by a core developer with commit access, that would be the only extra-step needed by a non-core developer. As suggested before, I think we should even make the original author of the patch the actual "owner" of the ticket. In practice, the patch should be first made on the relevant branch: 0.11-stable for bug fixes, trunk for a new feature, or a topic branch when relevant (e.g. a patch for fixing a bug on multirepository support should be based on that branch, obviously). Fixes for 0.11-stable are then regularly ported to trunk, and from there, to topic branches. > In short, I would need a topic, some initial guidance, and regular > feedback. Does that sound reasonable? Absolutely ;-) > My current interest lies with multi-repository integration, as this is > the norm when using a DVCS. Is this topic desired? Any chance of > finding a "problem of intermediate size" on this topic, and somebody > willing to push me in the right direction and review my contributions? There are tons of problems of intermediate size related to multirepos branch. I should probably document them on the corresponding wiki page, but here are a few examples: - small issue: visual glitch in Firefox for the new Rev column, where the changeset icon doesn't align properly to the right (but works fine for every other web browser) - "normal" feature: it's currently not possible to compare across repositories (the situation is detected, but raises a "not implemented" error). It would be quite useful to be able to do so, and it's doable without much work (only need to compare folders in a backend neutral way, we already do our own diff at the file level) - major feature (blocker): make the cache work again. In a first step, the existing cache could be adapted to simply handle more than one repository. A second (much) more ambitious step would be to generalize the cache so that it can support other (d)vcs. - etc. ;-) -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
