Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

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 even attempt moving everything to Github.


--
HM

--
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/56550a30-6b2d-3db6-0b35-0e6785e2af4d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

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 still stands. I've only managed to move a complete set of issues 
*once*, from trac to Bitbucket. IIRC there was an export-script which 
output I then hand-edited, *and* all contributors had users on bitbucket.



--
HM

--
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/11c6f178-fb5f-5280-3757-c836d4882759%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Jamesie Pic]

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 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/CAC6Op19Das4BwaiFSo8pRK6s0pcbSp5ECSDH83aoVyEe6DD3tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Abhinav tuteja]

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
> discussion on the
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> I was asking for more participation in general, and participation that is
> more representative of the wider Django community in particular.
>
> There was lots of good input from many people, including (but not, at all,
> limited to) representatives of groups such Pyladies, DjangoGirls, and so
> on.
>
>
> The recurring themes seem to me to fit into three categories:
>
>1. The importance of *mentoring*.
>2. The difficulty of *finding tickets*.
>3. The importance of *sprints*.
>
> The rest here is a summary of that. Hopefully it’s useful.
>
> Mentoring
>
> For whatever reasons, the exiting *Contributing How-To*
>  doesn’t
> lead to contributions from a demographic that matches the wider Django
> Community.
>
> The point that came up again and again about this was that *mentoring* is
> one of the best (perhaps the best?) tool in helping to change this.
>
> Django Core Mentorship
>
> We don’t have an official mentoring programme but we do have the 
> django-core-mentorship
> list .
>
> This must be about the best-kept secret in the Django world: it’s gets ≈0
> traffic, but I told everybody at DjangoCon about it, and that they should
> use it.
>
> If you are not on django-core-mentorship, and you’re willing to help
> prospective contributors, please sign-up. I’m hoping we can drive some
> traffic to it.
>
> Maybe there’s call for something more formal, but at least until DCM is
> actually being used, that seems (to me) like something we can postpone.
>
> Finding Tickets
>
> The next thing was that there’s not enough guidance on what to work on.
>
> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
> open tickets in TRAC. 13 of these are marked *Easy Pickings*.
>
> That’s not enough. I think we’re too tight with it (or need another
> grade).
>
> There are *many* tickets which aren’t super hard: I put it that, most of
> our community solve harder problems every day *using Django* than most
> tickets require.
>
> Yes, they still require time, love, energy, etc — and maybe some mentoring
> — but it’s not primary research, in the main.
>
> I talked to people who had (at the conference) got the test suite running
> and such, but been overawed by the (for want of a better phrase) *sheer
> face* of issue tracker.
>
> We would do well to invite people better here. (I don’t have instant
> solutions.)
>
> Sprints
>
> I’m not historically a Django-sprinter. (I have too many children for that
> TBH, but they’re getting older…)
>
> I always thought it was for a hard-core to work on hard issues.
>
> Shows what I know… 
>
> It was strongly impressed upon me that the real benefit of sprints is
> being able to give new contributors the support they need to make their
> first (or second or…) contribution.
>
> In particular, groups such as Pyladies can organise a sprint event with
> the specific goal of helping members of the community get across the
> barriers to contributing. This can reach numbers that otherwise simply
> aren’t possible. (So wow. Basically.)
>
> Sprints & Mentoring
>
> Obviously having mentors at sprints is a key component.
>
> But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be
> available at the right time to contribute remotely. Maybe, in fact, remote
> mentors are a key resource in more remote parts of the Django-sphere.
>
> It turns out just being on e.g. Twitter can be enough here.
>
> If we’re all on django-core-mentorship, maybe sprint organisers could post
> notice of an upcoming sprint.
>
> Sprints & Finding Tickets
>
> It turns out it’s equally hard for a sprint organiser to work out what
> tasks to give sprinters.
>
> At DjangoCon (some) people have a topic and asks others to join them. But,
> maybe if you’re short of experts and so on, that’s not necessarily a model
> that allows that scales out in other contexts.
>
> It was put to me that, if we had something like curated project boards
> (think Trello or GitHub projects) with groups of tickets… perhaps some
> easier, some harder… Perhaps with a *curating mentor*, even if remote… —
> *THEN* it becomes much easier for a small groups to organise a sprint,
> whatever their group may look like, wherever they may be.
>
> It struck me that, whilst 

Re: Widening participation (Thoughts from DjangoCon)

[Josh Smeaton]

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 the ticket status. 

But I don't have the time to plan or champion a change like that through 
these days, so while I'd like to see it happen, I'm not the person to push 
for it to happen.

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 

On Tuesday, 11 December 2018 23:20:21 UTC+11, Tom Forbes wrote:
>
> > 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 GH Issues
>
> I really think it's worth considering - I'm not convinced Trac is strictly 
> better from a feature perspective. Things like the dashboards are 
> interesting, sure, but what does it do that Github issues don't? And by 
> this I don't mean features that exist but we don't use, I mean our general 
> ticket workflow that 99% of contributors are exposed to. There are far 
> larger projects than Django currently using Github issues successfully and 
> they have a far more complex workflow including CLA's, high-granularity 
> tags, automatic reviewer selection, automatic closing, etc etc.
>
> The cost of a migration would not be cheap, but is it worth doing a formal 
> evaluation and consider it? The "why Github section" (
> https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists 
> some good reasons that apply to us as well. The key one for me is lowering 
> the barrier to entry which I think we should be aiming towards. If we are 
> looking to expand the development group and get more people onboard we may 
> need to shake things up, as the status quo is problematic in that area.
>
> On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com 
> ) wrote:
>
> 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 status quo which is strictly better from a feature 
> perspective than GH Issues. Incrementally improving Trac can improve the 
> value prop for not changing, but I don't think anyone that actually uses 
> Trac would say it's worse from a feature perspective. Even if that value 
> judgement did land on GH issues side, there would still be a large 
> operational undertaking to make that transition. 
>
> Again, the PEP for doing this for CPython would be very similar for 
> Django, so please refer to https://www.python.org/dev/peps/pep-0581/ for 
> some examples of why and what operational concerns there can be (migration, 
> permissions, etc).
>
> On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote: 
>>
>> 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 ultimately benefit the framework 
>> as a whole.
>>
>> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote: 
>>>
>>> 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 >>>
> 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 
> .  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 

Re: Widening participation (Thoughts from DjangoCon)

[Jamesie Pic]

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 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 issue/comment is often owned by the importing user, and
> the username/email of the original contributor is mangled into the
> issue/comment-text itself.
>
> This looks so nice for an issue with 50+ different contributors when
> wind up being owned by the same user. Robert explains to Robert that
> Robert's patch won't work with Roberts latest PR because Robert pulled
> the wrong commit that Robert made to update the dependencies that
> Robert discovered needed to be updated because Robert found a security
> flaw, with apologies to Robert. There's usually no way to search for
> the actual contributors either. It is as if importing to such
> issue-systems are an after thought. Starting out with a design where
> user and contributor are two different but potentially linked objects
> would have solved the problem *correctly*.
> 
>
> [*] There are no doubt problems other than this, it's just the one
> that bugs me the most. Especially since the solution so often is "Drop
> all history, start from scratch."
>
> --
> 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/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAC6Op19n-sfO2mLFGiXs0ohodCHK-%2BYEw9k7_n1r%3DJfq7VAFZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

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 issue/comment is often owned by the importing user, and
the username/email of the original contributor is mangled into the
issue/comment-text itself.

This looks so nice for an issue with 50+ different contributors when
wind up being owned by the same user. Robert explains to Robert that
Robert's patch won't work with Roberts latest PR because Robert pulled
the wrong commit that Robert made to update the dependencies that
Robert discovered needed to be updated because Robert found a security
flaw, with apologies to Robert. There's usually no way to search for
the actual contributors either. It is as if importing to such
issue-systems are an after thought. Starting out with a design where
user and contributor are two different but potentially linked objects
would have solved the problem *correctly*.


[*] There are no doubt problems other than this, it's just the one
that bugs me the most. Especially since the solution so often is "Drop
all history, start from scratch."

-- 
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/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Tom Forbes]

> 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 GH Issues

I really think it's worth considering - I'm not convinced Trac is strictly
better from a feature perspective. Things like the dashboards are
interesting, sure, but what does it do that Github issues don't? And by
this I don't mean features that exist but we don't use, I mean our general
ticket workflow that 99% of contributors are exposed to. There are far
larger projects than Django currently using Github issues successfully and
they have a far more complex workflow including CLA's, high-granularity
tags, automatic reviewer selection, automatic closing, etc etc.

The cost of a migration would not be cheap, but is it worth doing a formal
evaluation and consider it? The "why Github section" (
https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists
some good reasons that apply to us as well. The key one for me is lowering
the barrier to entry which I think we should be aiming towards. If we are
looking to expand the development group and get more people onboard we may
need to shake things up, as the status quo is problematic in that area.

On 11 December 2018 at 12:04:32, Josh Smeaton (josh.smea...@gmail.com)
wrote:

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 status quo which is strictly better from a feature
perspective than GH Issues. Incrementally improving Trac can improve the
value prop for not changing, but I don't think anyone that actually uses
Trac would say it's worse from a feature perspective. Even if that value
judgement did land on GH issues side, there would still be a large
operational undertaking to make that transition.

Again, the PEP for doing this for CPython would be very similar for Django,
so please refer to https://www.python.org/dev/peps/pep-0581/ for some
examples of why and what operational concerns there can be (migration,
permissions, etc).

On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>
> 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 ultimately benefit the framework
> as a whole.
>
> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>>
>> 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 >>
 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
 .  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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%
 3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
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 

Re: Widening participation (Thoughts from DjangoCon)

[Josh Smeaton]

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 status quo which is strictly better from a feature 
perspective than GH Issues. Incrementally improving Trac can improve the 
value prop for not changing, but I don't think anyone that actually uses 
Trac would say it's worse from a feature perspective. Even if that value 
judgement did land on GH issues side, there would still be a large 
operational undertaking to make that transition. 

Again, the PEP for doing this for CPython would be very similar for Django, 
so please refer to https://www.python.org/dev/peps/pep-0581/ for some 
examples of why and what operational concerns there can be (migration, 
permissions, etc).

On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>
> 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 ultimately benefit the framework 
> as a whole.
>
> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>>
>> 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 >>
 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 
 .  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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>

-- 
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/127550d4-b2dd-4ad7-8e6e-b56a66080194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.