custom validation error in password_validators

[Mojtaba Akbari]

i wanna have custom validation error in password_validators,
I can do this by rewriting the password validator classes and adding 
desired messages through options in the settings file and the 
password_validat section.

something like this :

AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 
'django.contrib.auth.password_validation.NumericPasswordValidator',
'OPTIONS': {
'validation_error': 'My Custom Validation Error.',
},
},
...
]

and so on.

Apart from that I want to return custom validation error, for example in 
our company project we want to send our language based message without 
enabling t10n and l18n. Or ux writer wants to show the user the desired 
error according to business needs,
But it is not possible unless we directly override the password_validation 
classes and this is an extra and dirty work.

Is it worth the time? After spending some time, can I make a pull request?

-- 
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/1038c5e4-1d86-4c50-90e2-2df7b8c9894dn%40googlegroups.com.

Re: Changing the role of the Technical Board

[James Bennett]

Something I note here is that it's presenting a solution, but not clearly
(at least, from my reading) presenting the problem to be solved.

Is it a lack of people proposing features? If so, I'm not sure this helps
-- it would, to me, suggest that only members of the Technical
Board/Steering Council/whatever-it's called are supposed to do that, since
it's in their job description. Would people then expect to, or be expected
to, run for a seat in order to contribute something?

Is it a more general lack of engagement? If so, I'm still not sure how this
helps -- the idea of DEP 10 was to make it *easier* for people to step up
and get involved, since it got rid of the idea of the "core team" with
their special privileges, but I don't think any form of technical
governance actually solves engagement issues. At best it can make
engagement-specific efforts easier, but I don't see how re-centralizing
authority (or creating the impression of it) would achieve that.

Is it to make fundraising easier? That sounds again like something that
technical governance really can't do on its own -- it needs to involve the
DSF Board, and there are reasons why the DSF was historically wary about
doing targeted fundraising for specific features in Django.

Loosening eligibility is fine, though I agree it's going to be very
difficult to write down in an enforceable way -- the DEP 10 language and
process was intended primarily to prevent trolls and other bad-faith actors
from being able to run effectively for the Technical Board, and there's a
balance where the more you loosen it up, the more you also open the door
for those kinds of people.

Also, regarding the multiple roles restriction: it currently is allowed for
a single person to simultaneously be on both the Technical Board and the
DSF Board, and there are even procedures in DEP 10 for things like
mandatory recusal for DSF Board votes and actions that affect the Technical
Board. What's not allowed is simultaneously being a Merger and on the
Technical Board.

-- 
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/CAL13Cg-mWWK0%2Bzkvi%3DCWu0e%3DbX-rOsLq4gHHdBuKQ8UL_8pRSg%40mail.gmail.com.

Re: Changing the role of the Technical Board

[Andrew Godwin]

These are some great points, James - let me try to tackle them roughly in order.

Proposing features - this is already in DEP 10, so I more just want to get that 
aspect of the Board actually going (and, as a side-effect, have something to 
aid fundraising). I am talking with the current Board separately on an internal 
thread, where the current stance (not everyone has responded) is that I am 
personally happy to take on all the work here for now - but I want to make sure 
it's not just me in the long run, be that merely proving that the idea works or 
attracting board members who want to specifically mediate such discussions and 
interaction with the wider community.

Engagement - It's not about "lack of engagement", and I think any issues there 
are deeper problems with OSS communities and the fact that we have to learn to 
sustainably work with the people we have rather than throwing everything at 
trying to recruit fresh, new people. I have ideas around this topic 
specifically, but they will not be solved in terms of the Board alone.

Loosening eligibility - If you're up for it I would very much value your help 
here in terms of refining wording once I have a first draft. My initial 
direction was to still require the 18 month history of contributions, but widen 
it from "technical" to more kinds of work (obviously the discussion part is in 
there too, but I think in general we can do a bit more of an OR rather than an 
AND on the current requirements, keeping a minimum time of contribution to 
prevent bad actors)

Serving on the DSF Board - you are of course right, I misread the DEP last week.

Overall, if all we do is change the name and start actually doing calls for 
features as outlined in DEP 10, I'll honestly be happy - but I think, given the 
most recent TB election was uncontested and several long-time Django 
contributors have told me they'd be more willing to join a TB that was less 
strictly technical-all-the-time, that it makes sense for us to also look at 
those requirements.

Andrew

On Mon, Oct 24, 2022, at 2:54 PM, James Bennett wrote:
> Something I note here is that it's presenting a solution, but not clearly (at 
> least, from my reading) presenting the problem to be solved.
> 
> Is it a lack of people proposing features? If so, I'm not sure this helps -- 
> it would, to me, suggest that only members of the Technical Board/Steering 
> Council/whatever-it's called are supposed to do that, since it's in their job 
> description. Would people then expect to, or be expected to, run for a seat 
> in order to contribute something?
> 
> Is it a more general lack of engagement? If so, I'm still not sure how this 
> helps -- the idea of DEP 10 was to make it *easier* for people to step up and 
> get involved, since it got rid of the idea of the "core team" with their 
> special privileges, but I don't think any form of technical governance 
> actually solves engagement issues. At best it can make engagement-specific 
> efforts easier, but I don't see how re-centralizing authority (or creating 
> the impression of it) would achieve that.
> 
> Is it to make fundraising easier? That sounds again like something that 
> technical governance really can't do on its own -- it needs to involve the 
> DSF Board, and there are reasons why the DSF was historically wary about 
> doing targeted fundraising for specific features in Django.
> 
> Loosening eligibility is fine, though I agree it's going to be very difficult 
> to write down in an enforceable way -- the DEP 10 language and process was 
> intended primarily to prevent trolls and other bad-faith actors from being 
> able to run effectively for the Technical Board, and there's a balance where 
> the more you loosen it up, the more you also open the door for those kinds of 
> people.
> 
> Also, regarding the multiple roles restriction: it currently is allowed for a 
> single person to simultaneously be on both the Technical Board and the DSF 
> Board, and there are even procedures in DEP 10 for things like mandatory 
> recusal for DSF Board votes and actions that affect the Technical Board. 
> What's not allowed is simultaneously being a Merger and on the Technical 
> Board.
> 
> 
> -- 
> 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/CAL13Cg-mWWK0%2Bzkvi%3DCWu0e%3DbX-rOsLq4gHHdBuKQ8UL_8pRSg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe

Re: Changing the role of the Technical Board

[James Bennett]

On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin  wrote:

> Proposing features - this is already in DEP 10, so I more just want to get
> that aspect of the Board actually going (and, as a side-effect, have
> something to aid fundraising). I am talking with the current Board
> separately on an internal thread, where the current stance (not everyone
> has responded) is that I am personally happy to take on all the work here
> for now - but I want to make sure it's not just me in the long run, be that
> merely proving that the idea works or attracting board members who want to
> specifically mediate such discussions and interaction with the wider
> community.
>

I admit I haven't been following Django development all that closely since
I mic-dropped after DEP 10 passed, but this is worrying, because canvassing
for feature proposals is not an optional thing -- DEP 10 *requires* the
Technical Board to do this at least once per feature release of Django. Has
that not been occurring? Because if it hasn't, then we have a major
problem, and I don't see how the current proposal would resolve it.

Overall, if all we do is change the name and start actually doing calls for
> features as outlined in DEP 10, I'll honestly be happy - but I think, given
> the most recent TB election was uncontested and several long-time Django
> contributors have told me they'd be more willing to join a TB that was less
> strictly technical-all-the-time, that it makes sense for us to also look at
> those requirements.
>
> I have concerns about this because what it really feels like is a first
step toward merging the Technical Board and the DSF Board into a single
unified governance board of everything to do with Django, and I think the
split between governance of Django-the-codebase and
Django-the-everything-the-DSF-does is a useful and important one (not least
for legal reasons).

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

Re: Changing the role of the Technical Board

[Andrew Godwin]

> Has that not been occurring? Because if it hasn't, then we have a major 
> problem, and I don't see how the current proposal would resolve it.

It has not. While I cannot speak for the other members of the Board, I got 
burnt out in 2019, and then the pandemic began, and so it has not really been 
something I've pushed for in the past three years (and I believe I was one of 
the drivers of getting that in DEP 10 in the first place). We never really got 
into the rhythm of doing it, and I think a lot of us got busy or burnt out.

My personal belief is that if something is not working, it is time for a 
re-analysis of the situation and a change, even if what's written down in the 
rules is fine on its face.

This proposal is part of a larger set of community changes I would like to 
consider - I am, for obvious reasons, not blasting the community with them all 
at once, but I do believe that a strong, visible set of leaders, with a clearly 
outlined set of principles and shepherding a community-guided vision, is the 
most important thing to establish - both in terms of the Technical Board and 
the DSF Board.

I have a much longer blog post in me about my evolving belief in the need for 
visible, servant leaders in OSS communities rather than trying to embrace a 
flat hierarchy with mechanical checks and balances - but that is for another 
day.

Andrew

On Mon, Oct 24, 2022, at 4:26 PM, James Bennett wrote:
> On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin  wrote:
>> __
>> Proposing features - this is already in DEP 10, so I more just want to get 
>> that aspect of the Board actually going (and, as a side-effect, have 
>> something to aid fundraising). I am talking with the current Board 
>> separately on an internal thread, where the current stance (not everyone has 
>> responded) is that I am personally happy to take on all the work here for 
>> now - but I want to make sure it's not just me in the long run, be that 
>> merely proving that the idea works or attracting board members who want to 
>> specifically mediate such discussions and interaction with the wider 
>> community.
> 
> I admit I haven't been following Django development all that closely since I 
> mic-dropped after DEP 10 passed, but this is worrying, because canvassing for 
> feature proposals is not an optional thing -- DEP 10 *requires* the Technical 
> Board to do this at least once per feature release of Django. Has that not 
> been occurring? Because if it hasn't, then we have a major problem, and I 
> don't see how the current proposal would resolve it.
> 
>> Overall, if all we do is change the name and start actually doing calls for 
>> features as outlined in DEP 10, I'll honestly be happy - but I think, given 
>> the most recent TB election was uncontested and several long-time Django 
>> contributors have told me they'd be more willing to join a TB that was less 
>> strictly technical-all-the-time, that it makes sense for us to also look at 
>> those requirements.
>>> 
> I have concerns about this because what it really feels like is a first step 
> toward merging the Technical Board and the DSF Board into a single unified 
> governance board of everything to do with Django, and I think the split 
> between governance of Django-the-codebase and 
> Django-the-everything-the-DSF-does is a useful and important one (not least 
> for legal reasons). 
> 
> 
> -- 
> 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/CAL13Cg93CvLgVU567MsvqKZAiWVBxxm1-L_YuEUhjr_JRySBwg%40mail.gmail.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/6196974e-a1a5-4585-87ab-02f79509%40app.fastmail.com.

Re: Changing the role of the Technical Board

[James Bennett]

On Mon, Oct 24, 2022 at 6:33 PM Andrew Godwin  wrote:

> It has not. While I cannot speak for the other members of the Board, I got
> burnt out in 2019, and then the pandemic began, and so it has not really
> been something I've pushed for in the past three years (and I believe I was
> one of the drivers of getting that in DEP 10 in the first place). We never
> really got into the rhythm of doing it, and I think a lot of us got busy or
> burnt out.
>
> My personal belief is that if something is not working, it is time for a
> re-analysis of the situation and a change, even if what's written down in
> the rules is fine on its face.
>

Well.

My first reaction to this is: if having a DEP that says the Technical Board
is supposed to take the lead in gathering feature proposals didn't get them
to do it, it doesn't feel like another DEP saying they're responsible for
that is going to fix it.

And it's not just the lack of canvassing for features that's worrying; if
members of the Technical Board didn't feel they were up to the job, they
should have let someone know that. Getting burned out or overcommitted is a
thing that happens, and a thing that was anticipated in drafting the
governance -- DEP 10 has a procedure for it!

Why did no member of the Technical Board do that?

This proposal is part of a larger set of community changes I would like to
> consider - I am, for obvious reasons, not blasting the community with them
> all at once, but I do believe that a strong, visible set of leaders, with a
> clearly outlined set of principles and shepherding a community-guided
> vision, is the most important thing to establish - both in terms of the
> Technical Board and the DSF Board.
>
> I have a much longer blog post in me about my evolving belief in the need
> for visible, servant leaders in OSS communities rather than trying to
> embrace a flat hierarchy with mechanical checks and balances - but that is
> for another day.
>

And I strongly disagree -- I think Django is far better off without
centralized hierarchical leadership, which is why I wrote and pushed DEP
10. People who want to be technical leaders for Django are free to do so
already; there's no need to have to occupy a formally-titled hierarchical
role in the project's governance in order to do that. And the lack of
requirement for such a formally-titled role is crucial to ensuring other
people feel *they* can jump in and start contributing their technical
leadership, too.

But what's most bothering me is that, from the sound of it, the DEP 10
governance wasn't even really tried.

I know people have asked for Technical Board input at least a couple times
in threads on the django-developers list, and I've looked at them and I'm
having a hard time finding anything resembling what was supposed to happen
under the DEP. It seems clear that the duty to collect feature proposals
was not carried out. And from the sound of what you're saying in this
thread, the Technical Board is mostly communicating with itself about this,
in private, when the direction of Django is supposed to be worked out
publicly and transparently. That's why we shut down the old private
communication spaces for the former "core team" after DEP 10 was adopted.

So forgive me for being blunt, but: if the Technical Board is not following
the governance we have, I think replacing the Technical Board's current
membership should be higher on the list of remedies than replacing the
governance.

>

-- 
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/CAL13Cg-rdfueZarLYZhysCpK58-H1f080uXad1EmWj%2Bt9uR13Q%40mail.gmail.com.