Re: Proposal: Clarify individual members page

[Cory Zue]

Hey Andrew,

Thanks for drafting this language and I think it looks great. As someone
who only recently applied after hearing it discussed on an episode of
Django Chat[1], I'm all for the goals of making it more encouraging and
accessible and think this is a great step in that direction.

Here are a few minor thoughts to specific bits:

Service to the Django community takes many forms. Here are some examples
> (non-exhaustive) of categories of work performed by members:
>

"performed by members" is a little ambiguous as to whether it means "this
is how we evaluate applicants" vs "this is what you'll do if part of the
DSF". Since I think the intention is the former it might make sense to
change to something like:

*Service to the Django community takes many forms. Here are some
(non-exhaustive) examples of the categories of work that might qualify as
"service":*

Borrowed the list of categories from Andrew Godwin's DEP for the update to
> the technical board. Per Tim's recommendation, do we want to include
> anything about the review process?
>

When I applied I didn't (and still don't, really) have any visibility into
the process, so it wasn't a deterrent for me, personally, but I think
having information certainly wouldn't hurt. My two cents would be good to
put something in, but not necessarily if it slows down/stalls this change
if for whatever reason that isn't super easy, since I think this represents
an improvement on its own.

Also, I'm a little unsure about that last bit about applying, but I wanted
> to put something encouraging to folks to apply. Happy to reword that if
> someone has a better suggestion. I'd prefer that to having a full rubric
> for membership on this page, primarily because I think it would be very
> difficult to nail that down because the work that folks perform can be so
> disparate (must have run X django meetups, or triaged Y tickets).
>

Definitely agree a rubric would cause more problems than it would help at
this stage. The goals of rubrics in terms of increasing objectivity and
reducing bias are great, but as applied to the already-squishy definition
of "service to the community" it doesn't seem like a good fit here.

Finally, this is wildly out of scope, but it may make sense to (either here
or separately) attempt to create a bit more content about what it means to
be an individual member of the DSF. That information is also somewhat
lacking, and having it somewhere may encourage more people to apply. One
possibility could be to link to one of the recent conference talks[2][3] on
the DSF. But wouldn't want that discussion/information to slow down this
change.

cheers,
Cory

[1] https://djangochat.com/episodes/read-the-docs-eric-holscher
[2] https://www.youtube.com/watch?v=Z_e-QoeZwEM
[3] https://www.youtube.com/watch?v=uJnaEZkoVTg


> On Thursday, October 27, 2022 at 10:03:48 AM UTC-4 carlton...@gmail.com
> wrote:
>
>> That would be awesome, yes. Fresh eyes likely see more clearly :)
>>
>> And equally. :)
>>
>> Thanks.
>> C.
>>
>> On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com wrote:
>>
>>> Regarding Carlton's points, that does clarify, and I agree about the
>>> open ended qualifiers. I also agree with Tim's points. I'm not sure we need
>>> another membership level (I'm not opposed, though). Rather, I think making
>>> the current page more transparent will help more folks feel welcome and
>>> hopefully get more folks (who do fit the criteria) to apply.
>>>
>>> If someone wants to draft new language, that would be great. If not, I
>>> may have some time next week to try.
>>>
>>> Thanks,
>>> Andrew
>>>
>>> P.S. Great meeting both of you at Djangocon last week!
>>> On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill...@gmail.com
>>> wrote:
>>>
 Hi Carlton,

 I think I might have been one of those people mentioning the lack of
 definition around the membership requirements. It has held me back from
 applying (finally sent one in yesterday). Given the process's obscurity
 (see below), it's daunting to hit submit.

- The number of potential qualifiers is open ended.
   - This should remain, unaltered. It makes the application more
   daunting, but it's also encouraging in that any contribution is 
 valid.
   - The degree of involvement per qualifier is not defined.
   - This seems like something that could be done. The review
   process must have a rubric of some sort.
   - There is a valid argument to be made that making statements
   about minimum levels of requirement could lead to a person disputing 
 a
   rejection.
   - The review process is not included on the form.
   - Some people will appreciate having more information on how the
   process works.
   - The people who will see this application are not included on
the form.
   - I know the DSF Board is doing at least part of the approvals

Re: Add a minimal Gitignore

[Cory Zue]

Is there a more nuanced discussion of this issue anywhere? The reasons
stated in the linked PR that it's "not for the project template to provide
configuration for source code management tools" feels more like an opinion
than a fact.

 I know one of the goals that emerged from recent discussions was how to
get more wide adoption of the Django project. This strikes me as one of
those simple little things that helps 95% of beginners and doesn't hurt the
remaining 5%. If you don't want a .gitignore file, then you're also
probably advanced enough to figure out how to build without it, or just
delete it.

I just checked a few other frameworks:

Rails new automatically
 generates a
.gitignore by default, has an option to exclude it
.
Drupal / composer added it in 2020 .
create-react-app  generates
one.
create-vue  generates one

Perhaps it's time for Django to reconsider and catch up with the times?

Cory




On Fri, Mar 10, 2023 at 7:03 AM Mariusz Felisiak 
wrote:

> Hi Daniel,
>
> Adding .gitignore to the project template has been discussed and
> rejected multiple times, e.g. https://github.com/django/django/pull/13847
>
> Best,
> Mariusz
>
> --
> 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/fd500891-f348-488a-863b-04c372d1bf4bn%40googlegroups.com
> 
> .
>

-- 
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/CALojRn_3vXWedquYVAwrv1L0oLXX%3DsmpbK7_TsfJa0nZP0%2BeFQ%40mail.gmail.com.

Re: Add a minimal Gitignore

[Cory Zue]

Hey,

Thanks, I appreciate the response. It sounds like your main concern is the
overhead of maintaining the .gitignore file, is that right? Could that
potentially be mitigated by a clear writeup of what's included, why, and
then an easy way to close all other tickets? E.g. we could easily just use
github's Python default, declare that the policay, and call it day. Perhaps
that overhead would be no less than having to have this conversation over
and over again as it seems clear has already been happening.

As for the point that not everyone uses git, that's true, but according to
the latest SO survey it's used by 94% of respondents
.
That seems like a pretty solid majority to help support, no?

thanks,
Cory

On Fri, Mar 10, 2023 at 10:39 AM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> Hi,
>
> I'm -1. "Other frameworks..." is not an argument for me, and I don't
> believe that `.gitignore` in the project template makes it more beginner
> friendly as I wouldn't call a beginner someone who use VCS.
>
> Adding `.gitignore` assumes that folks always use Git, that's not true.
> Moreover, `.gitignore` is IDE-specific in most of cases, and we don't want
> to accept dozens of tickets for expanding `.gitignore` with `.idea`,
> `.vscode` etc.
>
> My 2¢
>
> Best,
> Mariusz
>
> --
> 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/4aac7240-50b8-4dc0-8baf-70503941dea4n%40googlegroups.com
> 
> .
>

-- 
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/CALojRn-awFEPJXVf1bYedyWVOSk_na2PD3X3cec3-hGk5Z1g8w%40mail.gmail.com.

Re: Celery Working Limitations Updates

[Cory Zue]

I agree with Ken, that this a Celery issue, not a Django one.

But while we're here, as far as I know Celery still runs fine on windows.
It is not officially supported, and the default pool no longer works, but
if you run celery with --pool=solo (in development) or --pool=gevent (in
production) it should run without problems. You might run into issues, as
the Celery developers highlight, but I would expect that for a relatively
normal use case it might be fine.

There is also the upcoming background worker support to consider if it
suits your use case:
https://www.djangoproject.com/weblog/2024/may/29/django-enhancement-proposal-14-background-workers/

Cory

On Thu, Aug 22, 2024 at 4:36 PM 'Ken Whitesell' via Django developers
(Contributions to Django itself)  wrote:

> I think you're misinterpreting what you're reading from your search
> results.
>
> This is a Celery issue, not a Django issue.
>
> Quoting from the Celery docs at
> https://docs.celeryq.dev/en/stable/faq.html#does-celery-support-windows
>
> -
> Does Celery support Windows?
> 
> 
>
> *Answer*: No.
>
> Since Celery 4.x, Windows is no longer supported due to lack of resources.
>
> But it may still work and we are happy to accept patches.
>
> -
>
> On 8/21/2024 9:03 AM, Muhammad Shariq Shafiq wrote:
>
> Hello Dear Django Team
>
> Last month, I tried to do some task of django which primarily based on
> scheduling of accessibility with time and role based authnetications
>
> I used celery for that scheduling but failed and for 2 days i tried for it
> by changing my code logic and urls but all in vain
>
> Then i read from google that django has no longer support of celery for
> windows user. Which is not a good for developers
>
> We have to make things easy for developers to captivate the ideas into
> reality without any limitatoons.
>
> My suggestion and request to you to make celery working again on windows
> so that the developers can use it effeciently and produces more productivity
>
> Regards
> --
> 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/08095574-14fc-425e-b36a-59c095f0dc07n%40googlegroups.com
> 
> .
>
>
> --
> 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/4b4bbca5-5023-4029-b043-5fc577cb7b9d%40comcast.net
> 
> .
>

-- 
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/CALojRn_QFJxWVBgaC45t_Wq016eqd2P2yQqFsBh0niPbA4hAgA%40mail.gmail.com.