Re: Widening participation (Thoughts from DjangoCon)

Hi everyone, It's been great to read some good insights on this discussion. How to attract new contributors from a different demographic (geographic area and age)? Good question. I wanted to share with you my experience as (second year) organization administrator and mentor for OpenWISP

Re: Widening participation (Thoughts from DjangoCon)

Le jeudi 13 décembre 2018 09:17:49 UTC+1, Carlton Gibson a écrit : > > ... > I'd like to push on these avenues (and similar) before we take on the > massive project of changing systems. > (Ultimately I think we'd change system and find ourselves in exactly the > same boat.) > Thanks Carlton,

Re: Widening participation (Thoughts from DjangoCon)

Thanks for the discussion all. FWIW, I think Trac is OK. We have a massive history there, which is valuable. And you don't need the commit bit to be able to triage tickets. I don't think moving to another system solves the problem: we'd still have 1400 accepted open tickets, which is too

Re: Widening participation (Thoughts from DjangoCon)

Regarding Gitlab: I love gitlab and for organizations it's one of if not the best tools in its space. But it falls down for projects like Django, and I don't think moving migrating the code from GitHub is a good idea. The labels would need automating, which would require a GitHub bot of some

Re: Widening participation (Thoughts from DjangoCon)

On 12/11/18 8:38 PM, Josh Smeaton wrote: Jamesie: please see "Why not Gitlab?" [0]. While it might be better from a technical standpoint, it would not be better than GH Issues from an onboarding perspective. [0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab Note that they didn't

Re: Widening participation (Thoughts from DjangoCon)

On 12/12/18 12:34 AM, Jamesie Pic wrote: Thanks Josh, love your link, seems like it dates from 2017 during the period when GitLab UI was redesigned. But GitLab is still emerging as a standard tool no matter what. I'm currently attempting to move some issues from github to gitlab. The rant

Re: Widening participation (Thoughts from DjangoCon)

Thanks Josh, love your link, seems like it dates from 2017 during the period when GitLab UI was redesigned. But GitLab is still emerging as a standard tool no matter what. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django

Re: Widening participation (Thoughts from DjangoCon)

Hey i do also code in django can we talk ? On Fri, 26 Oct 2018 at 7:15 PM, Carlton Gibson wrote: > Hi All. > > OK, so last week I was at DjangoCon US in San Diego. (Thank you if you > organised that! Hi! if we met and chatted.) > I gave a talk ("Your web framework needs you!") inspired by the >

Re: Widening participation (Thoughts from DjangoCon)

For what it's worth, I agree. I think we should consider using GitHub issues. I don't think there's anything in Trac, from a user perspective, that we couldn't really do with Issues. The main issue, I think, would be allowing non-committers (organisational members) to triage tickets and change

Re: Widening participation (Thoughts from DjangoCon)

Gitlab should be mentioned as a vastly superior alternative to trac + GitHub + jenkins. Le mar. 11 déc. 2018 à 14:01, Hanne Moa a écrit : > Whenever I've had to move from one issue-system to another, the main > pain point has always been issue/comment ownership[*]. This is because > many

Re: Widening participation (Thoughts from DjangoCon)

Whenever I've had to move from one issue-system to another, the main pain point has always been issue/comment ownership[*]. This is because many systems want a login-capable, verified user for every single person that have ever made an issue or comment. If there is no 1-to-1 mapping, the

Re: Widening participation (Thoughts from DjangoCon)

> The only reason Github issues would be a consideration is if the group thought the onboarding experience (being where users already are with a tool they're already familiar with) would have more value than sticking with with the status quo which is strictly better from a feature perspective than

Re: Widening participation (Thoughts from DjangoCon)

I don't think something like Jira would even be a consideration. The only reason Github issues would be a consideration is if the group thought the onboarding experience (being where users already are with a tool they're already familiar with) would have more value than sticking with with the

Re: Widening participation (Thoughts from DjangoCon)

Apologies for the double post - my last one was not clear. "just that" means that the payment is intended to indicate that it is worth a JIRA license to me to not use JIRA. This group does great things. I am sure that the group can come up with some interesting ways to scale that will

Re: Widening participation (Thoughts from DjangoCon)

FWIW: Please consider my contribution of $84 (one bulk JIRA license for one year) to be just that. On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote: > > I'd pay money to NOT use Jira. > > On Mon, Dec 10, 2018, 11:09 AM Dan Davis > wrote: > >> Tom, you are right about the

Re: Widening participation (Thoughts from DjangoCon)

This project probably qualifies here: https://www.atlassian.com/software/views/open-source-license-request On Monday, December 10, 2018 at 2:05:40 PM UTC-5, Ira Abbott wrote: > > Hi, > > Just in case that JIRA crack was NOT sarcasm ... > > https://www.atlassian.com/software/jira/pricing How

Re: Widening participation (Thoughts from DjangoCon)

I'd pay money to NOT use Jira. On Mon, Dec 10, 2018, 11:09 AM Dan Davis 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 >

Re: Widening participation (Thoughts from DjangoCon)

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

Re: Widening participation (Thoughts from DjangoCon)

And there might be no need to develop code for this, only configuration: https://github.com/dnephin/TracAdvancedSearchPlugin On Mon, Dec 10, 2018 at 11:22 AM Dan Davis wrote: > I think that TracSearch could use improvement. As an expert in > Information Retrieval, I would be happy to help

Re: Widening participation (Thoughts from DjangoCon)

I think that TracSearch could use improvement. As an expert in Information Retrieval, I would be happy to help with this. The particular suggestions I have: - Provide quick filters (e.g. facets) after a search is done based on ticket keywords, stage, and whether a result is a ticket,

Re: Widening participation (Thoughts from DjangoCon)

> I strongly dislike Trac in nearly every way. It's hard to search and the filters are next to useless, and the categorisation features we use are not very useful. > I believe the better way to search Trac is to use google and site: code.djangoproject.com which is a red flag itself. Is there a

Re: Widening participation (Thoughts from DjangoCon)

Hi, >From the perspective of someone who just joined the group, I am glad to see that I was not alone not immediately finding the correct path or participation. I am, however grateful that the community appears to have the introspection and means of moving it forward. Being new, I am curious

Re: Widening participation (Thoughts from DjangoCon)

This is prompted by James Bennet's article yesterday which prompted a discussion with a coworker of mine. I've been using django for a while now, am a mid-level at a company that uses django/DRF heavily, and am a regular lurker here because its

Re: Widening participation (Thoughts from DjangoCon)

Trac can be made easier to search with Apache Solr - https://www.pycon.it/conference/talks/full-text-search-for-trac-with-apache-solr On Sunday, October 28, 2018 at 6:04:12 PM UTC-4, Josh Smeaton wrote: > > I strongly dislike Trac in nearly every way. It's hard to search and the > filters are

Re: Widening participation (Thoughts from DjangoCon)

I strongly dislike Trac in nearly every way. It's hard to search and the filters are next to useless, and the categorisation features we use are not very useful. I believe the better way to search Trac is to use google and site:code.djangoproject.com which is a red flag itself. On Saturday, 27

Re: Widening participation (Thoughts from DjangoCon)

An alternative that might work well is to triage tickets to mentors, so that a list of tickets with willing mentors is available. It would feel less judge-y than "easy pickings" and also broaden the pool of tickets that could be worked by a newcomer. Of course it hinges on a willing pool of

Re: Widening participation (Thoughts from DjangoCon)

Hi Carlton, I've had similar thoughts sitting in the back of my mind for at least a couple of months, so thank you for sharing this. I agree that finding tickets is one of the big problems here, both for new contributors and for sprint leaders. At Pycon UK I took on the role of sprint leader

Re: Widening participation (Thoughts from DjangoCon)

Thanks. Although I don't solve the demographic problem, I should respond to the call for broader participation. I should make myself put aside time to contribute - and I should force my boss to let me ;) On Fri, Oct 26, 2018 at 9:44 AM Carlton Gibson wrote: > Hi All. > > OK, so last week I

Widening participation (Thoughts from DjangoCon)

Hi All. OK, so last week I was at DjangoCon US in San Diego. (Thank you if you organised that! Hi! if we met and chatted.) I gave a talk ("Your web framework needs you!") inspired by the discussion on the DSF list and