The more I use Trac, the more I appreciate its power. I'm normally all for Progress™ but I'm not sure GitHub's UI is up to it. (Being able to find the old discussion is super handy: it's not that often that an idea has not come up before at this stage.)
*I'd be interested to see what a prototype export looks like in a test GitHub repo. Maybe it's possible... (Note this is in bold.)* Maybe more people would participate, but I'm not sure... Do we just suspect that? I worry we go to a load of effort for no real gain. Current input is quite good I'd say. Claude and Simon are regulars. There's a good number more who make frequent appearances. I think there's more people commenting than we suspect. (Anyone trying the export would be able to do numbers I'd guess...) If the new Triaging role on GH would allow "Request a review..." I think it would be super handy. (But currently that's restricted to the more powerful roles.) (I'm nagging GH about as best I can but if anyone knows anyone...) Happy to comment more if people want, but those are the highlights. C. On Wednesday, 7 August 2019 12:56:18 UTC+2, Josh Smeaton wrote: > > Mariatta has put together a some PEPs for migrating CPython issues over to > GitHub. > > https://www.python.org/dev/peps/pep-0581/ proposing the migration. > https://www.python.org/dev/peps/pep-0588/ migration plan. > > Django and Cpython are not the same, so there'll be substantial > differences. But it's worth familiarising oneself with prior art. > > For what it's worth I'd strongly support such a move just for the increase > in engagement. > > Carlton, Mariusz, how would you gauge the level of triage activity in Trac > from non-core members? High/Medium/Low? > > https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/ > describes > the new triage and maintain roles, but they're still to be granted to > trusted individuals (which would be an excellent gateway into full core > membership if that is the direction Django is going to continue in). > > On Wednesday, 7 August 2019 17:46:18 UTC+10, John Gooding wrote: >> >> Hi Aymeric, >> >> You bring up a lot of good points. There will undoubtedly be challenges >> and huge amount of work in moving to a new system, or implementing any big >> sweeping changes, however, I truly honestly believe that it would be worth >> it in the long run, and the payoff would far outweigh the cost. >> >> As far as Microsoft owning github, etc I think it is almost moot. Any >> process will have some amount of vendor lock in, whether github, atlassian >> (jira & bitbucket parent company), or even gitlab. I think what is >> important is to pick one system as a community that we are happy with. Any >> one of those three could do what is ultimately needed, which is a >> centralized and consistent development platform. >> >> On Wednesday, August 7, 2019 at 12:33:59 AM UTC-7, Aymeric Augustin wrote: >>> >>> Hello John, >>> >>> This was discussed before, when we moved from self-hosted svn to >>> GitHub-hosted git, but I'm not sure there are public archives of all >>> discussions. >>> >>> As far as I remember, the main points to tackle are: >>> >>> 1. Does GitHub allow "anonymous triage" i.e. labelling, closing, and >>> reopening issues by non-committers? I think there was a recent announcement >>> in this area. I didn't check the details. Previously, bot-powered >>> workarounds were suggested, but they wouldn't provide a good user >>> experience. You want discoverable buttons, not a cheat sheet of magic >>> comments. >>> >>> 2. Does the GitHub UI scale to thousands of issues? In theory, any >>> classification system can be reproduced with namespaced labels e.g. >>> "component:ORM", "status:ready-for-checkin", etc. In practice, it's >>> unlikely to be as convenient as what currently exists on Trac. >>> >>> Perhaps it's just me, but I always found GitHub issues hard to use when >>> I had more than on page of issues. Indeed, at that point, I need a >>> labelling system to filter issues. Then I need to keep all the rules of >>> that system in my head instead of having the UI guide me — and prevent me >>> from infringing the system... >>> >>> 3. How do we migrate issues history from Trac to GitHub? Preserving >>> comment authorship doesn't seem obvious, especially for authors who don't >>> have the same username on Trac and GitHub or authors who don't have a >>> GitHub account. >>> >>> Initially an effort was made to sync usernames of core devs between Trac >>> and GitHub to prevent security problems but that's a small subset of >>> contributors. >>> >>> 4. Are we still able to export everything from GitHub and move on to the >>> next thing? Perhaps there's an obvious answer. I didn't look. Usually >>> Django takes a pragmatic position: we won't reject GitHub outright because >>> it isn't open source. However, we wouldn't want to lock ourselves into a >>> platform we don't control. >>> >>> Who would have bet, three years ago, that GitHub would be the property >>> of Microsoft today? What if Microsoft sells it to Oracle in three years? >>> It's nice to keep our options open :-) >>> >>> We put the code there because we were confident that we could pull the >>> git history. Then everyone started using pull requests, which was likely a >>> good thing, but wasn't really planned or thought through, and I don't think >>> we can export PR comments meaningfully. GitHub did some good vendor lock in >>> there. >>> >>> 5. How do we preserve links to SVN commits? Currently, they're >>> redirected on https://code.djangoproject.com/ with this nginx rule: >>> >>> rewrite ^/changeset/(\d+)/?$ >>> https://www.djangoproject.com/svntogit/$1/ permanent; >>> >>> and then redirected again by this application: >>> >>> https://github.com/django/djangoproject.com/tree/master/svntogit >>> >>> It would be nice to preserve these links in issues copied from Trac to >>> GitHub, which probably means pre-processing comments to rewrite links. >>> >>> There may be more, but that's what comes to mind! >>> >>> A process DEP >>> <https://github.com/django/deps/blob/master/final/0001-dep-process.rst#dep-types> >>> is >>> the way to go to propose this change. >>> >>> Best regards, >>> >>> -- >>> Aymeric. >>> >>> >>> >>> On 7 Aug 2019, at 08:24, John Gooding <ja.g...@gmail.com> wrote: >>> >>> I'd like to propose moving Django issues to github and make a real >>> decision on it here in this thread. If there has been a recent discussion >>> on this I apologize, but searching for issue tracking / github links to >>> about every thread ever posted here. >>> >>> I believe this would lower the barrier to entry and to help promote >>> community involvement. People are already there, people already use it, and >>> we already do pull requests there. Now I could be wrong here, but I also >>> feel that it would improve and promote discussion about changes and feature >>> additions to Django, because right now they are pretty hidden away in the >>> current system. >>> >>> I'd also like to see the inclusion of a "discussion" label or similar >>> for issues. I think many of the conversations here on this forum would be >>> much better off as github issues. I see a lot of great stuff, and it's not >>> clear at all what the status is, has it moved forward, been officially >>> denied? etc. If they are github issues they will have definitive >>> resolutions, whatever it may be, and links to relevant code, PR's etc if >>> needed. >>> >>> I think there is a huge amount to gain by consolidating the ticket >>> system and many of the discussions on this forum into github's issue >>> tracker. I don't see any reason why it wouldn't be wroth the effort, and we >>> only have much to gain as a community from it. But that's just my 2 cents. >>> I'd love to hear what others think, for or against it. >>> >>> John >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-d...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/da5ca4b1-fb84-4ed4-b2cb-324b8bea9c42%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/da5ca4b1-fb84-4ed4-b2cb-324b8bea9c42%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b9b9713b-6ca8-467d-b0ab-818ae1a7ee68%40googlegroups.com.
