Hi, Just in case that JIRA crack was NOT sarcasm ...
https://www.atlassian.com/software/jira/pricing How many users would be needed? If going this way, I smell the need for a gateway / JIRA backend for the community site and small number of actual JIRA users with the creation coming from a single user with some sort of 'community-user' data field patched in. JIRA is certainly flexible and configurable this way and capable of interface to other enterprise apps. We would have to find out how to make this work within their terms of service ... Otherwise, its probably "BYOL" for contributors at about <$7 / month. i.e. possibly "$7/month for each month active", though I think they will change for a constant number, which means managing floaters. While new to this community, I suspect that any other arrangement than these two is prohibitive. And even managing floaters for anyone not locked in by commitment (contract) to the group adds risk to the group from the whatever commitment exists with Atlassian for any fixed number. This could potentially bankrupt the group if not managed correctly. My other advice is to "KISS" when using JIRA. All that configuration can lead to a tendency for organizations to attempt to solve all of their problems building workflows there. This is VERY STICKY, hence the behemoth that Atlassian has become and will continue to be for some time in to the future. Finally, any major changes such as this are like an a manufacturing organization changing ERP packages (been through several of those) - they NEVER GO WELL, and inevitably, when the smoke clears users will long for the old system despite its glaring deficiencies. I therefore will hold that improvements should be made to Trac in an incremental Agile fashion rather than any conversion requiring a waterfall rollout. This is the part where Trac should be STICKY for the group, or this will be disruptive. And besides, I like Python in general and don't to fall victim to 'pay to play' to Atlassian / Oracle to develop open source software that, believe me, refers everything Python as 'a bunch of scripts'. I get enough of that at work which is part of why I am here. Regards, Ira On Monday, December 10, 2018 at 12:10:05 PM UTC-5, Dan Davis wrote: > > Tom, you are right about the UX issues, but full-text and inverted > indexing would help with the responsiveness as well. Technically, I was > talking about djangoproject's TracSearch > <https://code.djangoproject.com/search>. That's closer to good UX as > well, because you can get there by progressive enhancement rather than > taking stuff away. > > You are also right that switching to another system such as github issues > could be a better fix than customizing Trac. But I find it difficult to > believe that Github issues grows up to cover as much workflow management as > Trac issues or JIRA. Maybe we need money to get JIRA. > > > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c5b4316c-7381-46bb-aba9-535147bccc66%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
