5 ms·

Personally, I find this quite timely, because I recently wanted to get involved in open source and looked into working with Django. Their ticket tracking system

Personally, I find this quite timely, because I recently wanted to get involved in open source and looked into working with Django. Their ticket tracking system looks far easier to follow and get involved with than many other large projects, but still I find zero tickets marked 'easy pickings' and 'unassigned'. This may be the wrong response, but my takeaway is that the project is too far along for new contributors, so it's better to try and get involved with smaller, less well known projects where I can contribute. In part, I'm commenting because I would love for this to not be true, and would be quite excited if someone pointed out flaws in my understanding!

pjtr 8y ago
If you like that ticket tracking system (Trac), maybe consider getting involved with that itself as well: https://trac.edgewall.org/query?status=new&keywords=~bitesized&desc=1&order=id https://trac.edgewall.org/query?status=new&keywords=~bitesiz... 'bitesized' tickets are "small work items, ideal for new contributors to dive into the code". https://trac.edgewall.org/wiki/HowToContribute https://trac.edgewall.org/wiki/HowToContribute
- jamestimmins 8y ago
  Oh this is quite cool, I assumed it was developed in-house. Thanks very much!
- bionoid 8y ago
  Just out of random interest - does anyone know what happened to the Apache Bloodhound project [0], which was based on Trac? I was somewhat optimistic when it started.. let's be real, Trac has many serious shortcomings, but it's still extremely practical for a small team of technical users. No progress was made on GenericTrac [1] whatsoever for the 5+ years I ran Trac in production and followed the project. Bloodhound made a single release, and then I never heard a word about it again. [0] http://bloodhound.apache.org/ http://bloodhound.apache.org/ [1] https://trac.edgewall.org/wiki/GenericTrac https://trac.edgewall.org/wiki/GenericTrac
  - pjtr 8y ago
    It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects. GenericTrac was mainly a plan by Christian Boos, who worked a lot on Trac in ~2005 - 2013, but has not actively worked on it much after that. Apache Bloodhound was mainly triggered by one company (WANdisco), which has lost interest in it. Of the few remaining people, Ryan J Ollos has since become a Trac core developer instead, and has been keeping very active there. Recently Gary Martin (formerly(?) WANdisco) "restarted" Apache Bloodhound as a Django app, not based on Trac anymore.[2] > Trac has many serious shortcomings I don't disagree, but would be interested in what you think they are. [2] https://lists.apache.org/list.html?dev@bloodhound.apache.org:2018-10 https://lists.apache.org/list.html?dev@bloodhound.apache.org...
    - bionoid 8y ago
      First let me say that I haven't looked at Trac since I ditched it from production (prior to the Bloodhound incubator). So don't expect this to be fair criticism today. > It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects. I am not convinced that is the only reason. The trac mailing list was (in my opinion) hostile to people that showed up with an idea and willingness to work on it; nobody would give encouragement or guidance and there was usually a "fk off and fork" or two in there. People aren't going to stick around to contribute if the maintainers/community are not interested to include them. That is/was a serious shortcoming. The data model was not well thought out, with lots of UNION and UNION ALL in the queries, row-modelling things that should be normalized, and so on. That's probably my #1 technical issue, in terms of the code, it was hard to correctly add functionality because things were just read into RAM and manipulated there (expert SQL knowledge is of no use when working with the trac database) The switch of templating engine did not make the codebase simpler, but instead made everything more convoluted and difficult to work with. The primary issue though, was the lack of Milestone customization, and the incredibly poor performance. I had to implement custom search, custom indexes, custom reports, and custom everything else. And this was a 5-person team, using only ticketing (no repo, no wiki, nothing).
feydaykyn 8y ago
I am in the same boat so I dug some more and here is a list of easy tickets : https://code.djangoproject.com/query?status=!closed&easy=1 https://code.djangoproject.com/query?status=!closed&easy=1
- throwmeback 8y ago
  everytime I go there, the tickets are already assigned.
  - feydaykyn 8y ago
    It seems so ! They suggest others ideas on the contributing page [0] : - Improve the documentation or write unit tests. - Triage tickets and review patches created by other users. I also imagine that reaching committers through irc will bring some ideas to work on. [0] https://docs.djangoproject.com/en/dev/internals/contributing/ https://docs.djangoproject.com/en/dev/internals/contributing...
    - jamestimmins 8y ago
      I see a lot of projects recommend triaging tickets or writing unit tests, but those both seem to be areas that require substantial knowledge about the state of a project, so as a newbie they don't feel accessible. It would be cool to see lists of how you can triage (e.g. encouraging people to help reproduce) or add tests (e.g. areas that could use more tests).
      - ubernostrum 8y ago
        Possible I'm unusual, but I actually like writing documentation as a way to learn a new codebase. When I started a new job earlier this year I actually jumped at the chance to grab some documentation tickets, because it meant I had to not just halfheartedly skim through the relevant code but actually read it in detail and understand what was going on. (and, of course, I ended up finding a bug)
      - feydaykyn 8y ago
ubernostrum 8y ago
I have some ideas about how to improve that. But will probably be a little while before I can do anything with those ideas, since right now all my Django-related time is going into the governance proposal.
- jamestimmins 8y ago
  That would be much appreciated! I'd love to get involved with Django. Best of luck with the proposal!

pjtr 8y ago

If you like that ticket tracking system (Trac), maybe consider getting involved with that itself as well: https://trac.edgewall.org/query?status=new&keywords=~bitesized&desc=1&order=id https://trac.edgewall.org/query?status=new&keywords=~bitesiz... 'bitesized' tickets are "small work items, ideal for new contributors to dive into the code". https://trac.edgewall.org/wiki/HowToContribute https://trac.edgewall.org/wiki/HowToContribute

jamestimmins 8y ago
Oh this is quite cool, I assumed it was developed in-house. Thanks very much!
bionoid 8y ago
Just out of random interest - does anyone know what happened to the Apache Bloodhound project [0], which was based on Trac? I was somewhat optimistic when it started.. let's be real, Trac has many serious shortcomings, but it's still extremely practical for a small team of technical users. No progress was made on GenericTrac [1] whatsoever for the 5+ years I ran Trac in production and followed the project. Bloodhound made a single release, and then I never heard a word about it again. [0] http://bloodhound.apache.org/ http://bloodhound.apache.org/ [1] https://trac.edgewall.org/wiki/GenericTrac https://trac.edgewall.org/wiki/GenericTrac
- pjtr 8y ago
  It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects. GenericTrac was mainly a plan by Christian Boos, who worked a lot on Trac in ~2005 - 2013, but has not actively worked on it much after that. Apache Bloodhound was mainly triggered by one company (WANdisco), which has lost interest in it. Of the few remaining people, Ryan J Ollos has since become a Trac core developer instead, and has been keeping very active there. Recently Gary Martin (formerly(?) WANdisco) "restarted" Apache Bloodhound as a Django app, not based on Trac anymore.[2] > Trac has many serious shortcomings I don't disagree, but would be interested in what you think they are. [2] https://lists.apache.org/list.html?dev@bloodhound.apache.org:2018-10 https://lists.apache.org/list.html?dev@bloodhound.apache.org...
  - bionoid 8y ago
    First let me say that I haven't looked at Trac since I ditched it from production (prior to the Bloodhound incubator). So don't expect this to be fair criticism today. > It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects. I am not convinced that is the only reason. The trac mailing list was (in my opinion) hostile to people that showed up with an idea and willingness to work on it; nobody would give encouragement or guidance and there was usually a "fk off and fork" or two in there. People aren't going to stick around to contribute if the maintainers/community are not interested to include them. That is/was a serious shortcoming. The data model was not well thought out, with lots of UNION and UNION ALL in the queries, row-modelling things that should be normalized, and so on. That's probably my #1 technical issue, in terms of the code, it was hard to correctly add functionality because things were just read into RAM and manipulated there (expert SQL knowledge is of no use when working with the trac database) The switch of templating engine did not make the codebase simpler, but instead made everything more convoluted and difficult to work with. The primary issue though, was the lack of Milestone customization, and the incredibly poor performance. I had to implement custom search, custom indexes, custom reports, and custom everything else. And this was a 5-person team, using only ticketing (no repo, no wiki, nothing).

feydaykyn 8y ago

I am in the same boat so I dug some more and here is a list of easy tickets : https://code.djangoproject.com/query?status=!closed&easy=1 https://code.djangoproject.com/query?status=!closed&easy=1

throwmeback 8y ago
everytime I go there, the tickets are already assigned.
- feydaykyn 8y ago
  It seems so ! They suggest others ideas on the contributing page [0] : - Improve the documentation or write unit tests. - Triage tickets and review patches created by other users. I also imagine that reaching committers through irc will bring some ideas to work on. [0] https://docs.djangoproject.com/en/dev/internals/contributing/ https://docs.djangoproject.com/en/dev/internals/contributing...
  - jamestimmins 8y ago
    I see a lot of projects recommend triaging tickets or writing unit tests, but those both seem to be areas that require substantial knowledge about the state of a project, so as a newbie they don't feel accessible. It would be cool to see lists of how you can triage (e.g. encouraging people to help reproduce) or add tests (e.g. areas that could use more tests).
    - ubernostrum 8y ago
      Possible I'm unusual, but I actually like writing documentation as a way to learn a new codebase. When I started a new job earlier this year I actually jumped at the chance to grab some documentation tickets, because it meant I had to not just halfheartedly skim through the relevant code but actually read it in detail and understand what was going on. (and, of course, I ended up finding a bug)
    - feydaykyn 8y ago

ubernostrum 8y ago

I have some ideas about how to improve that. But will probably be a little while before I can do anything with those ideas, since right now all my Django-related time is going into the governance proposal.

jamestimmins 8y ago
That would be much appreciated! I'd love to get involved with Django. Best of luck with the proposal!