Re: [python-committers] List of all core developers

[M.-A. Lemburg]

On 02.08.2018 23:07, Brett Cannon wrote:
> On Wed, 1 Aug 2018 at 14:44 M.-A. Lemburg  wrote:
> 
>> On 01.08.2018 23:28, Mariatta Wijaya wrote:
>>> See also an open issue to revamp the Developer log:
>>> https://github.com/python/devguide/issues/390
>>>
>>> Someone has also said that they're working on tracking down the dormant
>>> core devs, but now I can't find that email.
>>
>> I think the log is fine at it is, since it serves a different
>> purpose.
>>
> 
> What is the purpose? I don't remember why we started to keep the developer
> log in that format as I have never felt the need to go back and see who
> vouched for someone or who granted the commit rights in the end.

It's good to know in which context someone received the commit
bit and who was driving it. This is part of our history and
we should maintain it as documentation of the process we have
in place for becoming a core developer.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 03 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] List of all core developers

[M.-A. Lemburg]

On 02.08.2018 23:16, Brett Cannon wrote:
> On Thu, 2 Aug 2018 at 00:32 M.-A. Lemburg  wrote:
> 
>> On 02.08.2018 03:24, Eric V. Smith wrote:
>>> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote:
 I think it would also be a good idea to include core developers
 of other Python implementations in such a document, in
 separate sections, e.g. for Jython, IronPython, PyPy,
 Stackless, etc


 Hmm, I don't think it is should be our (CPython) responsibility to
 keep track and maintain the list of the core devs of alternate Python
 implementations. Don't they have their own community / website? They
 have their own repo, bug tracker, governance model, and everything,
 right?
>>>
>>> Agreed. We have a hard enough time keeping track of our own core
>>> developers.
>>
>> I don't really think we have a hard time doing this. The only
>> problem is that we never sat down and actually properly recorded
>> this in one place.
>>
>> Other projects will, of course, have their own websites, but since
>> Python is more than just CPython, it would be great to include those
>> other developers in an official list as well. It would be up for
>> for the other teams to maintain their lists.
>>
>> That said, this part is lower priority than the CPython core
>> developer listing.
>>
>>> For our core devs, can't we just say that the CPython core devs are
>>> those with commit bits on the CPython repo? I realize that will
>>> eliminate some people who have been core developers and never moved to
>>> github, but if they bring it to our attention, we can add them easily
>>> enough.
>> As discussed before, being a core developer is a status you
>> gain and never lose. There is a clear difference between have
>> commit rights to the (current) repo and this status.
>>
> 
>> What I am after, is a list of core developers, not a list of
>> people with their keys on github (or where ever we move in the
>> future), since this list is not about a technical status, but rather
>> a social one.
>>
> 
> Then the issue I created which Mariatta linked to I think covers this
> desire to have a historical record of people who have been core developers
> along with when they have had commit privileges.

Yes, it does, but it's not a replacement, it's an additional
simple to query reference for 3rd parties.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 03 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] List of all core developers

[M.-A. Lemburg]

Please note that the motivation for having a list similar to the
one we have for PSF Fellows is not to determine voting eligibility.

This is about having a record of the core developer status available
to show to 3rd parties, e.g. to (potential) employers, organizations,
government agencies, etc.

Having a place to also record the email addresses for internal
use such a voting or sending messages to the whole group
is a good idea nonetheless. This mailing list will likely already
serve that purpose.


On 02.08.2018 23:25, Brett Cannon wrote:
> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer 
> wrote:
> 
>> Again, this was in the (poorly conveyed) context of getting email
>>> addresses for them, or at least being able to contact them.
>>>
>>
>> I always thought there were already at least three places containing the
>> necessary email addresses.
>>
>> * python-committers should be exactly this mailing list.
>>
> 
> The list also has email archiving services as well as duplicate emails for
> people (e.g. I'm in it twice so that if I accidentally send an email from a
> personal email address it doesn't get held up in moderation).
> 
> 
>> * according to https://devguide.python.org/coredev/#issue-tracker it is
>> mandatory for core developers to subscribe to the issue tracker which AFAIK
>> requires a confirmed email address.
>>
> * Every committer clearly must have signed the contributor agreement
>> https://www.python.org/psf/contrib/contrib-form/ which also contains a
>> mandatory email field
>>
>> So why is it still necessary to get email addresses at all?
>>
> 
> Because none of those necessarily have accurate email addresses at this
> point. E.g. even python-committers has had people dropped off due to too
> many email rejections. And if we hold a vote for a governance model we will
> need a place to send ballots.
> 
> Now if the vote is open to any core developer (using MAL's definition of it
> being a lifetime title), then the subscription list for this mailing list
> is probably good enough with some manual grooming as long we are okay with
> long-dormant folk who predate this list not voting (which I'm personally
> fine with). But if we wanted a way to reach just people with commit
> privileges then that's a separate challenge.
> 
> -Brett
> 
> 
>>
>> 2018-08-02 10:59 GMT+02:00 Eric V. Smith :
>>
>>> On 8/2/2018 3:32 AM, M.-A. Lemburg wrote:
>>>
 On 02.08.2018 03:24, Eric V. Smith wrote:

> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote:
>
>>  I think it would also be a good idea to include core developers
>>  of other Python implementations in such a document, in
>>  separate sections, e.g. for Jython, IronPython, PyPy,
>>  Stackless, etc
>>
>>
>> Hmm, I don't think it is should be our (CPython) responsibility to
>> keep track and maintain the list of the core devs of alternate Python
>> implementations. Don't they have their own community / website? They
>> have their own repo, bug tracker, governance model, and everything,
>> right?
>>
>
> Agreed. We have a hard enough time keeping track of our own core
> developers.
>

 I don't really think we have a hard time doing this. The only
 problem is that we never sat down and actually properly recorded
 this in one place.

>>>
>>> I was specifically thinking of a way to stay in touch with core devs, or
>>> more specifically a way to send them email. In the past, before we moved to
>>> github, I took it upon myself to find email addresses (current or not) for
>>> all core devs, and I gave up without much success.
>>>
>>> I agree that we could probably come up with a list of names for people
>>> who have been given the "core dev" status.
>>>
>>> For our core devs, can't we just say that the CPython core devs are
> those with commit bits on the CPython repo? I realize that will
> eliminate some people who have been core developers and never moved to
> github, but if they bring it to our attention, we can add them easily
> enough.
>
 As discussed before, being a core developer is a status you
 gain and never lose. There is a clear difference between have
 commit rights to the (current) repo and this status.

>>>
>>> Agreed. Again, this was in the (poorly conveyed) context of getting email
>>> addresses for them, or at least being able to contact them.
>>>
>>> Eric
>>>
>>> ___
>>> python-committers mailing list
>>> python-committers@python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> 
> 
> 
> ___

Re: [python-committers] List of all core developers

[Donald Stufft]

We should probably have a single source of truth for what a core developer is, 
and all other systems pull from that.

> On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg  wrote:
> 
> Please note that the motivation for having a list similar to the
> one we have for PSF Fellows is not to determine voting eligibility.
> 
> This is about having a record of the core developer status available
> to show to 3rd parties, e.g. to (potential) employers, organizations,
> government agencies, etc.
> 
> Having a place to also record the email addresses for internal
> use such a voting or sending messages to the whole group
> is a good idea nonetheless. This mailing list will likely already
> serve that purpose.
> 
> 
> On 02.08.2018 23:25, Brett Cannon wrote:
>> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer 
>> wrote:
>> 
>>> Again, this was in the (poorly conveyed) context of getting email
 addresses for them, or at least being able to contact them.
 
>>> 
>>> I always thought there were already at least three places containing the
>>> necessary email addresses.
>>> 
>>> * python-committers should be exactly this mailing list.
>>> 
>> 
>> The list also has email archiving services as well as duplicate emails for
>> people (e.g. I'm in it twice so that if I accidentally send an email from a
>> personal email address it doesn't get held up in moderation).
>> 
>> 
>>> * according to https://devguide.python.org/coredev/#issue-tracker it is
>>> mandatory for core developers to subscribe to the issue tracker which AFAIK
>>> requires a confirmed email address.
>>> 
>> * Every committer clearly must have signed the contributor agreement
>>> https://www.python.org/psf/contrib/contrib-form/ which also contains a
>>> mandatory email field
>>> 
>>> So why is it still necessary to get email addresses at all?
>>> 
>> 
>> Because none of those necessarily have accurate email addresses at this
>> point. E.g. even python-committers has had people dropped off due to too
>> many email rejections. And if we hold a vote for a governance model we will
>> need a place to send ballots.
>> 
>> Now if the vote is open to any core developer (using MAL's definition of it
>> being a lifetime title), then the subscription list for this mailing list
>> is probably good enough with some manual grooming as long we are okay with
>> long-dormant folk who predate this list not voting (which I'm personally
>> fine with). But if we wanted a way to reach just people with commit
>> privileges then that's a separate challenge.
>> 
>> -Brett
>> 
>> 
>>> 
>>> 2018-08-02 10:59 GMT+02:00 Eric V. Smith :
>>> 
 On 8/2/2018 3:32 AM, M.-A. Lemburg wrote:
 
> On 02.08.2018 03:24, Eric V. Smith wrote:
> 
>> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote:
>> 
>>> I think it would also be a good idea to include core developers
>>> of other Python implementations in such a document, in
>>> separate sections, e.g. for Jython, IronPython, PyPy,
>>> Stackless, etc
>>> 
>>> 
>>> Hmm, I don't think it is should be our (CPython) responsibility to
>>> keep track and maintain the list of the core devs of alternate Python
>>> implementations. Don't they have their own community / website? They
>>> have their own repo, bug tracker, governance model, and everything,
>>> right?
>>> 
>> 
>> Agreed. We have a hard enough time keeping track of our own core
>> developers.
>> 
> 
> I don't really think we have a hard time doing this. The only
> problem is that we never sat down and actually properly recorded
> this in one place.
> 
 
 I was specifically thinking of a way to stay in touch with core devs, or
 more specifically a way to send them email. In the past, before we moved to
 github, I took it upon myself to find email addresses (current or not) for
 all core devs, and I gave up without much success.
 
 I agree that we could probably come up with a list of names for people
 who have been given the "core dev" status.
 
 For our core devs, can't we just say that the CPython core devs are
>> those with commit bits on the CPython repo? I realize that will
>> eliminate some people who have been core developers and never moved to
>> github, but if they bring it to our attention, we can add them easily
>> enough.
>> 
> As discussed before, being a core developer is a status you
> gain and never lose. There is a clear difference between have
> commit rights to the (current) repo and this status.
> 
 
 Agreed. Again, this was in the (poorly conveyed) context of getting email
 addresses for them, or at least being able to contact them.
 
 Eric
 
 ___
 python-committers mailing list
 python-committers@python.org
 https://mail.python.org/mailman/listinfo/python-committers
 Code of Conduct: https://www.python.org

Re: [python-committers] Reminder of BDFL succession timeline + CFP

[Jack Jansen]

> On Aug 3, 2018, at 02:19, Yury Selivanov  wrote:
> 
> OTOH, it would be great if we can at least set a date to start the
> discussion so that everybody can plan for it and join.  That's the
> only way to keep the discussion open and equally accessible for
> everyone.  If we do nothing, then naturally, those core devs who know
> each other personally will start forming their opinion in isolated
> groups. Many people will feel that they are completely removed from
> the decision process and will end up in a very uncomfortable position.

Hmm, you’re right. Not having any sort of timeline or process will mean that 
lots of stakeholders will not know about any discussions and feel left out by 
the end.

Some sort of a schedule would ameliorate that.

Jack
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] List of all core developers

[Brett Cannon]

On Fri, 3 Aug 2018 at 00:44 Donald Stufft  wrote:

> We should probably have a single source of truth for what a core developer
> is, and all other systems pull from that.
>

Ah, but I think there might be a terminology clash here. Using MALs
definition means that you can be a core developer but not have commit
privileges due to relinquishing those privileges at some point. So I'm not
sure what systems you are referring to that need to know if someone
historically happened to be a core developer.

Assuming what you mean is people with commit privileges, then we have the
"lovely" complication of usernames being inconsistent for people across
systems which is probably what is required to make any centralized list
useful for systems to interact with. We could solve this by using a table
instead of a list for people to list e.g. their GitHub and b.p.o usernames
if people wanted to go that route.


>
> > On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg  wrote:
> >
> > Please note that the motivation for having a list similar to the
> > one we have for PSF Fellows is not to determine voting eligibility.
> >
> > This is about having a record of the core developer status available
> > to show to 3rd parties, e.g. to (potential) employers, organizations,
> > government agencies, etc.
> >
> > Having a place to also record the email addresses for internal
> > use such a voting or sending messages to the whole group
> > is a good idea nonetheless. This mailing list will likely already
> > serve that purpose.
> >
> >
> > On 02.08.2018 23:25, Brett Cannon wrote:
> >> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer <
> stefan.richtho...@gmail.com>
> >> wrote:
> >>
> >>> Again, this was in the (poorly conveyed) context of getting email
>  addresses for them, or at least being able to contact them.
> 
> >>>
> >>> I always thought there were already at least three places containing
> the
> >>> necessary email addresses.
> >>>
> >>> * python-committers should be exactly this mailing list.
> >>>
> >>
> >> The list also has email archiving services as well as duplicate emails
> for
> >> people (e.g. I'm in it twice so that if I accidentally send an email
> from a
> >> personal email address it doesn't get held up in moderation).
> >>
> >>
> >>> * according to https://devguide.python.org/coredev/#issue-tracker it
> is
> >>> mandatory for core developers to subscribe to the issue tracker which
> AFAIK
> >>> requires a confirmed email address.
> >>>
> >> * Every committer clearly must have signed the contributor agreement
> >>> https://www.python.org/psf/contrib/contrib-form/ which also contains a
> >>> mandatory email field
> >>>
> >>> So why is it still necessary to get email addresses at all?
> >>>
> >>
> >> Because none of those necessarily have accurate email addresses at this
> >> point. E.g. even python-committers has had people dropped off due to too
> >> many email rejections. And if we hold a vote for a governance model we
> will
> >> need a place to send ballots.
> >>
> >> Now if the vote is open to any core developer (using MAL's definition
> of it
> >> being a lifetime title), then the subscription list for this mailing
> list
> >> is probably good enough with some manual grooming as long we are okay
> with
> >> long-dormant folk who predate this list not voting (which I'm personally
> >> fine with). But if we wanted a way to reach just people with commit
> >> privileges then that's a separate challenge.
> >>
> >> -Brett
> >>
> >>
> >>>
> >>> 2018-08-02 10:59 GMT+02:00 Eric V. Smith :
> >>>
>  On 8/2/2018 3:32 AM, M.-A. Lemburg wrote:
> 
> > On 02.08.2018 03:24, Eric V. Smith wrote:
> >
> >> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote:
> >>
> >>> I think it would also be a good idea to include core developers
> >>> of other Python implementations in such a document, in
> >>> separate sections, e.g. for Jython, IronPython, PyPy,
> >>> Stackless, etc
> >>>
> >>>
> >>> Hmm, I don't think it is should be our (CPython) responsibility to
> >>> keep track and maintain the list of the core devs of alternate
> Python
> >>> implementations. Don't they have their own community / website?
> They
> >>> have their own repo, bug tracker, governance model, and everything,
> >>> right?
> >>>
> >>
> >> Agreed. We have a hard enough time keeping track of our own core
> >> developers.
> >>
> >
> > I don't really think we have a hard time doing this. The only
> > problem is that we never sat down and actually properly recorded
> > this in one place.
> >
> 
>  I was specifically thinking of a way to stay in touch with core devs,
> or
>  more specifically a way to send them email. In the past, before we
> moved to
>  github, I took it upon myself to find email addresses (current or
> not) for
>  all core devs, and I gave up without much success.
> 
>  I agree that we could probably come up wi

Re: [python-committers] Reminder of BDFL succession timeline + CFP

[Barry Warsaw]

On Aug 1, 2018, at 12:41, Mariatta Wijaya  wrote:
> 
> Since this is like a CFP I figured we should clarify what's expected the 
> proposal, and I also wanted to be more detailed in the timeline.
> 
> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance model.

Thanks for writing this up Mariatta.  I think it’s very useful to put stakes in 
the ground so that these discussions don’t drag on forever.  I agree with those 
who say that the status quo is an implicit choice of governance models, and I 
think we shouldn’t operate under implicit rules for too long.  Like Brett, I 
often have folks coming up to me and asking me what’s going on, and when Python 
will decide on a governance model.  Let’s not underestimate the message this 
sends to the outside world.

OTOH, we do have some flexibility in the timeline, and I still believe that we 
have flexibility in the governance model over the long term.  I’ve no doubt 
that no matter what we choose, the debate will continue, with ebbs and flows as 
situations arise.  That may even lead to new (or adjusted) governance models in 
the future, and that’s fine!  Unlike with Python itself, we aren’t bound to 
strict backward compatibility. :)

That said, I think it’s worthwhile capturing the proposed governance models in 
PEPs so that we all know exactly what we’re debating.  October 1st for that 
round of PEP submissions is quite reasonable IMHO.  Procedurally, I suggest we 
segregate governance model PEPs in their own 4th digit namespace (e.g. like the 
way Python 3k started at the 3000s).  8 seems like a good number; we reserve 
the lower 8ks for “special” PEPs (the problem statement, the choice, the voting 
procedure, etc.).

We can be a little more loose on the voting schedule, but like Brett, I would 
like to have a decision by the end of 2018, even if that decision is an 
explicit choice of status quo.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] List of all core developers

[Donald Stufft]

> On Aug 3, 2018, at 1:52 PM, Brett Cannon  wrote:
> 
> 
> 
> On Fri, 3 Aug 2018 at 00:44 Donald Stufft  > wrote:
> We should probably have a single source of truth for what a core developer 
> is, and all other systems pull from that.
> 
> Ah, but I think there might be a terminology clash here. Using MALs 
> definition means that you can be a core developer but not have commit 
> privileges due to relinquishing those privileges at some point. So I'm not 
> sure what systems you are referring to that need to know if someone 
> historically happened to be a core developer.

We have that I am aware of right now:

- GitHub
- bugs.p.o
- python-committers

And it sounds like Marc-Andre is looking to add to it:

- A third party/user facing list of developers, regardless of the technical 
status of their ability to commit (e.g. even if they don’t have a GitHub 
account).


There may be other systems that I can’t recall off the top of my head (is 
anything still in hg.python.org ? I dunno).

As of right now, I believe the list of who a core developer is and has 
historically been somewhat adhoc based upon who has permissions to commit 
things. Meaning that as we transition from one system to another we “lose” the 
ability to account for people over the years. This would also make it harder 
for someone to come back, because they’d have to track down someone who knew 
they were a core developer (and let’s be honest, human memory sucks so 
sometimes you’re just not sure if someone was or wasn’t).

So I think it would probably be a good thing if we had one central location 
that answers the question of who is and isn’t a core developer, that isn’t tied 
to the ACLs of one particular system that we happen to be using today. Ideally 
these other related systems (bugs.p.o, Github, etc) are then modified to pull 
from this thing as the singular source of truth. This could be as simple as a 
CSV/tom/yaml file sitting in a repository somewhere that lists all of the 
developers, their status etc, plus scripts that will synchronize access from 
that to the relevant places.

So for arguments sake, it could be a CSV file with the schema:

Name, Email, Active, bugs.p.o Username, GitHub username

And then a script that could be ran whenever that would check the permissions 
of the GitHub team for CPython, and ensure that anyone listed there has been 
added to the GitHub team (and probably anyone who isn’t, has been removed, to 
ensure that getting in this file is the _way_ you get access). Likewise 
bugs.p.o could pull from this, and Marc-Andre’s public facing list could as 
well.

Of course we can get fancier than a simple file somewhere, the key thing is 
that there is a single source of truth, that isn’t tied to one particular 
service or tool that we use (unless that tool is dedicated to managing this 
list of people), because anytime we tie maintaining this list of people to the 
technical aspects of giving someone an ACL to a particular system, then our 
list is going to become outdated anytime we switch systems (and some % of 
people won’t ever make the jump to the new system).

> 
> Assuming what you mean is people with commit privileges, then we have the 
> "lovely" complication of usernames being inconsistent for people across 
> systems which is probably what is required to make any centralized list 
> useful for systems to interact with. We could solve this by using a table 
> instead of a list for people to list e.g. their GitHub and b.p.o usernames if 
> people wanted to go that route.
>  
> 
> > On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg  > > wrote:
> > 
> > Please note that the motivation for having a list similar to the
> > one we have for PSF Fellows is not to determine voting eligibility.
> > 
> > This is about having a record of the core developer status available
> > to show to 3rd parties, e.g. to (potential) employers, organizations,
> > government agencies, etc.
> > 
> > Having a place to also record the email addresses for internal
> > use such a voting or sending messages to the whole group
> > is a good idea nonetheless. This mailing list will likely already
> > serve that purpose.
> > 
> > 
> > On 02.08.2018 23:25, Brett Cannon wrote:
> >> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer  >> >
> >> wrote:
> >> 
> >>> Again, this was in the (poorly conveyed) context of getting email
>  addresses for them, or at least being able to contact them.
>  
> >>> 
> >>> I always thought there were already at least three places containing the
> >>> necessary email addresses.
> >>> 
> >>> * python-committers should be exactly this mailing list.
> >>> 
> >> 
> >> The list also has email archiving services as well as duplicate emails for
> >> people (e.g. I'm in it twice so that if I accidentally send an email from a
> >> personal email address it doesn't get held up in moderation).
> >> 
> >> 
> >>> *