[gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

This was something the Java team used to do long ago. We used to meet once a 
month and discuss what each was working on. How much time each felt they would 
have for Gentoo over the next month. We discussed common direction for the 
project and other things that really helped coordinate development efforts and 
make a pretty functional team and project. Sadly that ended.

I think that should be expanded as a require for a project. If a project is 
formed, it should be required to report on a monthly basis to the council. It 
does not have to meet monthly, but that is a good idea is will really save 
time in any reporting to Council. This does not require allot of time. It has 
many benefits not only within the project, but to the council and Gentoo.

https://wiki.gentoo.org/wiki/User:Wltjr/GLEP:Project_Monthly_Reports

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Johannes Huber]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

Am Donnerstag, 19. Januar 2017, 13:45:39 CET schrieb William L. Thomson Jr.:
> This was something the Java team used to do long ago. We used to meet once a
> month and discuss what each was working on. How much time each felt they
> would have for Gentoo over the next month. We discussed common direction
> for the project and other things that really helped coordinate development
> efforts and make a pretty functional team and project. Sadly that ended.
> 
> I think that should be expanded as a require for a project. If a project is
> formed, it should be required to report on a monthly basis to the council.
> It does not have to meet monthly, but that is a good idea is will really
> save time in any reporting to Council. This does not require allot of time.
> It has many benefits not only within the project, but to the council and
> Gentoo.
> 
> https://wiki.gentoo.org/wiki/User:Wltjr/GLEP:Project_Monthly_Reports

And when the projects are not doing it, projects get disbanded. Meaning 
packages go to single maintainer only. Which means reporting goes away.
Great plan!

Best regards,
Johannes

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Thursday, January 19, 2017 9:32:57 PM EST Johannes Huber wrote:
>
> And when the projects are not doing it, projects get disbanded. Meaning
> packages go to single maintainer only. Which means reporting goes away.
> Great plan!

If projects are not doing it, and packages fall to a single maintainer. Then 
should it even really be a project? A project/team ideally is more than just 
one person. If it is just one person, it is not really a project or team. Just 
someone scratching their itches.

Any developer can work on anything. It does not have to be a project. If you 
are going to create a project, it should be taken some what seriously and 
reporting should be a part of that. Not to mention should consist of more than 
one. They should be seeking others to be part of the project team. If not 
seeking others, its a solo mission.

Without such reporting from projects how does the Council or anyone have a 
clue what is going on in Gentoo overall? Short of stopping by each project and 
doing research into each.

That said, NOTHING in the GLEP says projects are punished or dis-banned for 
failing to report. Developers are required, or recommended to use repoman. 
Does that mean someone who does not is removed as a developer?

At the same time Council should have authority and reason to end a project it 
if is not going anywhere, understaffed, etc. Again not having a project does 
not mean you cannot work on that stuff. So a project and the work an 
individual is doing is not related. If its individuals, plural, then a project 
make sense.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Johannes Huber]

Am Donnerstag, 19. Januar 2017, 15:47:46 CET schrieb William L. Thomson Jr.:
> On Thursday, January 19, 2017 9:32:57 PM EST Johannes Huber wrote:
> > And when the projects are not doing it, projects get disbanded. Meaning
> > packages go to single maintainer only. Which means reporting goes away.
> > Great plan!
> 
> If projects are not doing it, and packages fall to a single maintainer. Then
> should it even really be a project? A project/team ideally is more than
> just one person. If it is just one person, it is not really a project or
> team. Just someone scratching their itches.
> 
> Any developer can work on anything. It does not have to be a project. If you
> are going to create a project, it should be taken some what seriously and
> reporting should be a part of that. Not to mention should consist of more
> than one. They should be seeking others to be part of the project team. If
> not seeking others, its a solo mission.
> 
> Without such reporting from projects how does the Council or anyone have a
> clue what is going on in Gentoo overall? Short of stopping by each project
> and doing research into each.
> 
> That said, NOTHING in the GLEP says projects are punished or dis-banned for
> failing to report. Developers are required, or recommended to use repoman.
> Does that mean someone who does not is removed as a developer?
> 
> At the same time Council should have authority and reason to end a project
> it if is not going anywhere, understaffed, etc. Again not having a project
> does not mean you cannot work on that stuff. So a project and the work an
> individual is doing is not related. If its individuals, plural, then a
> project make sense.

We are not a company.

Best regards,
Johannes

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Thursday, January 19, 2017 9:49:25 PM EST Johannes Huber wrote:>
> We are not a company.

What does that have to do with organization and unified direction?

"The Debian Project has a carefully organized structure."
https://www.debian.org/intro/about#who

What is Gentoo? Just a bunch of individual projects going their own direction. 
Or something that comes together as one?

I guess it is bad for the Council to be aware of what is going in each 
project. I guess that is also bad for the community. None of that can lead to 
all projects working together in ways they may not be today. If they are aware 
of what others are up to.

It is about working together rather than in silos.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Johannes Huber]

> It is about working together rather than in silos.

It isnt. Please proove that we are not working together instead of creating 
theses without facts. I see a lot of communication in irc.

Best regards,
Johannes

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Friday, January 20, 2017 1:13:30 PM EST Johannes Huber wrote:
> > It is about working together rather than in silos.
> 
> It isnt. Please proove that we are not working together instead of creating
> theses without facts. I see a lot of communication in irc.

How does anyone know what each project is up to now?
How does the council know?
What about the general community?

There might be communication in each IRC channel but they do not overlap. This 
is about connecting all projects. Feeding their information back to council, 
and else where like News team, community, press, etc.

As shown some of this information used to be available in the GWN. Teams that 
meet and keep minutes or logs of such. Also are already generating this 
information.

Here is an example of that, there are more just like it
https://archives.gentoo.org/gentoo-dev/message/
ca1bbe0222e2d6b1ed92ea3c393f6ba5

Does anyone know whats going on in say Gentoo Java? As another example.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Rich Freeman]

On Fri, Jan 20, 2017 at 10:00 AM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
>
> Does anyone know whats going on in say Gentoo Java? As another example.
>

Do we really need to make every project issue a monthly report just to
notice that the Java team can't keep up with monthly reports?  I think
the last 300 emails you've sent out have already driven home the
message that you think more people should be working on Java.

-- 
Rich

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Sunday, January 22, 2017 10:39:04 AM EST Rich Freeman wrote:
> On Fri, Jan 20, 2017 at 10:00 AM, William L. Thomson Jr.
> 
> <wlt-ml@o-sinc.com> wrote:
> > Does anyone know whats going on in say Gentoo Java? As another example.
> 
> Do we really need to make every project issue a monthly report just to
> notice that the Java team can't keep up with monthly reports? 

Java was JUST an example. There is no Java team really and has not been for 
years. I would think that to a topic of concern for the council. Though seems 
to extend beyond just Java.

The council should be aware and concerned if areas of Gentoo are going 
neglected. So should the community. But this is not about showing neglect. 
This is more about active projects, than inactive.

At the same time, if areas are going neglected, people are aware yet do 
nothing. What does that say? People are surely not drawn to neglected 
technical projects.

> I think
> the last 300 emails you've sent out have already driven home the
> message that you think more people should be working on Java.

More people should be working on Gentoo. Java is just one area of neglect for 
some time. That is NOT the only area.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Rich Freeman]

On Sun, Jan 22, 2017 at 11:16 AM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sunday, January 22, 2017 10:39:04 AM EST Rich Freeman wrote:
>> On Fri, Jan 20, 2017 at 10:00 AM, William L. Thomson Jr.
>>
>> <wlt-ml@o-sinc.com> wrote:
>> > Does anyone know whats going on in say Gentoo Java? As another example.
>>
>> Do we really need to make every project issue a monthly report just to
>> notice that the Java team can't keep up with monthly reports?
>
> Java was JUST an example. There is no Java team really and has not been for
> years. I would think that to a topic of concern for the council.

Why would the Gentoo Council care more about the Java team than the
Java team itself does?

>
> At the same time, if areas are going neglected, people are aware yet do
> nothing. What does that say?

That they don't care much about the specific areas being neglected?
The people who are going to be most motivated to contribute to
specific areas of Gentoo are those who care the most about those
specific areas.  That's basically how Gentoo works.

-- 
Rich

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

On Sunday, January 22, 2017 12:44:38 PM EST Rich Freeman wrote:
> 
> Why would the Gentoo Council care more about the Java team than the
> Java team itself does?

When there is no team? Answer that one yourself.

Said another way. Why should the body responsible for Gentoo over all care at 
all if any areas of Gentoo are going neglected?

If any area is being neglected is anyone in roles of leadership doing anything 
to correct such? Or just not carrying because others do not?
 
> > At the same time, if areas are going neglected, people are aware yet do
> > nothing. What does that say?
> 
> That they don't care much about the specific areas being neglected?

Which means they do not care about Gentoo over all. They only care about the 
pieces they use or work with.

> The people who are going to be most motivated to contribute to
> specific areas of Gentoo are those who care the most about those
> specific areas.  That's basically how Gentoo works.

Which again means no one cares about Gentoo over all. No one cares to bring 
all the pieces together.

Gentoo doesn't really work. That is part of the misnomer.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Rich Freeman]

On Sun, Jan 22, 2017 at 12:55 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sunday, January 22, 2017 12:44:38 PM EST Rich Freeman wrote:
>
>> > At the same time, if areas are going neglected, people are aware yet do
>> > nothing. What does that say?
>>
>> That they don't care much about the specific areas being neglected?
>
> Which means they do not care about Gentoo over all. They only care about the
> pieces they use or work with.

Sure.  Why shouldn't they?

>
>> The people who are going to be most motivated to contribute to
>> specific areas of Gentoo are those who care the most about those
>> specific areas.  That's basically how Gentoo works.
>
> Which again means no one cares about Gentoo over all. No one cares to bring
> all the pieces together.

All the pieces do come together.  What pieces on Gentoo do you see not
working together?

>
> Gentoo doesn't really work. That is part of the misnomer.
>

Your conclusion doesn't follow.  The fact that Java on Gentoo doesn't
work doesn't mean that Gentoo doesn't work.  If people cared that much
about Java working on Gentoo, then it would work.

Care isn't measured in mailing list posts, it is measured in pull
requests and such.

-- 
Rich

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

On Sunday, January 22, 2017 2:27:58 PM EST Rich Freeman wrote:
>
> > Which means they do not care about Gentoo over all. They only care about
> > the pieces they use or work with.
> 
> Sure.  Why shouldn't they?

Someone or group should be looking after Gentoo over all. That was the idea 
behind the Council. To oversee Gentoo as a whole.
 
> >> The people who are going to be most motivated to contribute to
> >> specific areas of Gentoo are those who care the most about those
> >> specific areas.  That's basically how Gentoo works.
> > 
> > Which again means no one cares about Gentoo over all. No one cares to
> > bring
> > all the pieces together.
> 
> All the pieces do come together.  What pieces on Gentoo do you see not
> working together?

How do the various projects come together without any coordination or 
awareness? That anything comes together now is just by chance. Since projects/
teams are working on their own.

Are the Council and Trustees working together? Do either work with Infra? How 
about interacting with the various projects? Is there any interaction? Or just 
when someone brings something to the Council. Passive vs proactive.

> > Gentoo doesn't really work. That is part of the misnomer.
> 
> Your conclusion doesn't follow.  The fact that Java on Gentoo doesn't
> work doesn't mean that Gentoo doesn't work.  If people cared that much
> about Java working on Gentoo, then it would work.

Why do you assume I am only speaking about Gentoo Java? Is every aspect of 
Gentoo over staffed? Is Gentoo getting a new developer every month at minimum?
Java is NOT the only area of Gentoo suffering. It is one of the largest areas 
being neglected. Java packages can likely dwarf most other languages, short of 
C or C++.

Just about any where you look in Gentoo you will see things understaffed.

> Care isn't measured in mailing list posts, it is measured in pull
> requests and such.

That is another matter entirely. More neglect when the community tries to 
submit stuff as there is a lack of people to handle to process the PR. Which 
does not encourage more. Presently 135 PRs on Github.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Rich Freeman]

On Sun, Jan 22, 2017 at 2:45 PM, William L. Thomson Jr.
<wlt-ml@o-sinc.com> wrote:
> On Sunday, January 22, 2017 2:27:58 PM EST Rich Freeman wrote:
>>
>>
>> All the pieces do come together.  What pieces on Gentoo do you see not
>> working together?
>
> How do the various projects come together without any coordination or
> awareness? That anything comes together now is just by chance. Since projects/
> teams are working on their own.

It is hardly chance.  Things come together because we have policies
that enable things to come together, and when these policies are found
to be insufficient they are revised.

In any case, my point is that things ARE coming together.

>
> Just about any where you look in Gentoo you will see things understaffed.
>

That has always been true of Gentoo, and it is also true of every area
of every distro out there, and even every department in every
corporation out there.  There is always a constraint between supply
and demand.

The key principle in FOSS is that the demand can turn into the supply,
which is why it works.

-- 
Rich

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Friday, January 20, 2017 10:00:47 AM EST William L. Thomson Jr. wrote:
>
> As shown some of this information used to be available in the GWN. Teams
> that meet and keep minutes or logs of such. Also are already generating
> this information.
> 
> Here is an example of that, there are more just like it
> https://archives.gentoo.org/gentoo-dev/message/
> ca1bbe0222e2d6b1ed92ea3c393f6ba5
> 
> Does anyone know whats going on in say Gentoo Java? As another example.

Another, but link to reference log is broken due to Trac being discontinued.
https://marc.info/?l=gentoo-dev&m=117391309204085&w=2

Seems we the Java team did not regularly report the meeting summaries to -dev 
mailing list. All the meeting logs and history were lost when Trac wiki was 
taken down. I believe the data still exists but was not migrated.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Thu, 19 Jan 2017 15:47:46 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

>  If it is just one person, it is not really a project or team. Just 
> someone scratching their itches.

A project reducing itself to one person is not grounds for dissolution 
of a project.

Even if that project is inactive, it is not grounds for dissolution of the project.

Because sometimes there is no work to be done.

And sometimes the reduction to 1 is not long term.

And projects serve more than a grouping of people.

Projects serve as a proxy for ownership of packages, allowing
smooth transfer of maintainership of a collection of related packages
between maintainers.

Otherwise, some really large projects with lots of packages would
have dissolved to a single maintainer, somebody would have had to go
through and change hundreds of metadata.xml files, only to later acquire
a new member, requiring a reformulation of the project, and a repeat of 
going through and flipping the metadata.xml for no benefit.

Projects serve as a structure to make development easier and possible.

Not a structure to rap us over the knuckles. ( Though sometimes both happens,
its important to know which one happens in service of the other )


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Friday, January 20, 2017 10:19:14 AM EST Kent Fredric wrote:
> On Thu, 19 Jan 2017 15:47:46 -0500
> 
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> >  If it is just one person, it is not really a project or team. Just
> > 
> > someone scratching their itches.
> 
> A project reducing itself to one person is not grounds for dissolution
> of a project.

There is nothing in the GLEP that suggests such. I am not proposing such or 
seeking to even discuss. That would be another GLEP as to rules for formation 
and dissolution of projects. The furthest I went was maybe, for many of the 
reasons you stated. I am simply talking about reporting, not dissolution.

> Not a structure to rap us over the knuckles. ( Though sometimes both
> happens, its important to know which one happens in service of the other )

This has nothing to do with that. It is simply information being disseminate. 
Just like some of what used to be in the GWN.

Example

"Important changes within the Java Project
-----------------------------------------
A number of significant changes have happened within Gentoo's Java team...."
https://archives.gentoo.org/gentoo-gwn/message/
ae1382e71f3d57fd971e004e5950d4d0

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

On Thu, 19 Jan 2017 13:45:39 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> I think that should be expanded as a require for a project. If a project is 
> formed, it should be required to report on a monthly basis to the council. It 
> does not have to meet monthly

I think this starts out with a wrong priority. 

The framing here is that this structure is a stick to keep everyone in line,
and that the beatings shall continue to drive up morale. 

Where I think the priority needs to focus on *facilitating* progress, by creating
systems that *empower* and *enable* clearer communication, like making sure that
the donkey has somewhere to sleep at night and has plenty of water so it can actually
do its job the next day, instead of hoping a stick or carrot can be a magical solution.

As such, a mandatory scheme that requires projects to report back to an authority
is distasteful.

I'd rather a more informal structure, where somebody is appointed the task of polling
the different projects and asking them questions like: 

- Is there anything the project needs
- Are there any changes you're doing now or in the future that would be useful
  for people to know about ( including other members of the project )

And I would take more concern if given projects couldn't be reached for commentary.

If a project can be reached for commentary, but has nothing specific to report back,
then that should be fine.

If a project doesn't need to declare a need for anything from other projects,
or doesn't care to inform other projects what its doing, that should be fine.

There would naturally be some conceptual overlaps here with the GLEP 42 gentoo
news system, and some overlap with the Gentoo newsletter, and so anything that
falls into either of those would be good examples of things to mention, and
ear-tag as such. ( Which may potentially facilitate those groups )

As an adjunct, it might also be useful to have some sort of active "status board"
for different projects that can be edited by anyone easily and can easily be displayed
in bulk, and not have any real requirements on its frequency of change.

For example, to an extent IRC /topic's are used in a limited fashion for this sometimes.

But it needs a little more space than whatever that limit is.

But it doesn't ( and shouldn't ) need a full blank web page, and should ideally
be no larger than a moderate but concise git commit message.

So probably somewhere less painful to deal with than a wiki would be nice.

But this status board can help inform the person doing the polling and
others in a slightly more immediate fashion, not bound by clock cycles,
but by necessity.

And for groups who want to bother to sit down and have meetings,
brief outcomes from those meetings could be part of that status board,
perhaps with longer contents in links.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Friday, January 20, 2017 10:39:49 AM EST Kent Fredric wrote:
>
> The framing here is that this structure is a stick to keep everyone in line,
> and that the beatings shall continue to drive up morale.

You are taking this completely out of context.

Your repeated comments on beatings and morale, makes me some what question 
your line of thinking. More so given how you are completely misreading and 
making your own interpretation of things not even written in the GLEP.

> I'd rather a more informal structure, where somebody is appointed the task
> of polling the different projects and asking them questions like:

Oh yes, create more positions and roles no one wants to fulfill. Are you going 
to do that? Just another area/project/team to be understaffed. FYI this is 
what used to happen as part of the newsletter.

> As an adjunct, it might also be useful to have some sort of active "status
> board" for different projects that can be edited by anyone easily and can
> easily be displayed in bulk, and not have any real requirements on its
> frequency of change.

That is something that could be programmed into wiki pages for each project 
tracking commit activity. However it would still not tell you where the 
project/team is going or information about its activities.

> And for groups who want to bother to sit down and have meetings,
> brief outcomes from those meetings could be part of that status board,
> perhaps with longer contents in links.

That is in part what I am suggesting in a report provided to the council.

The reports I am suggesting, could be linked into the status board your 
suggesting. So your basically proposing the same thing in a different way.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

On Thu, 19 Jan 2017 16:59:09 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> On Friday, January 20, 2017 10:39:49 AM EST Kent Fredric wrote:
> >
> > The framing here is that this structure is a stick to keep everyone in line,
> > and that the beatings shall continue to drive up morale.  
> 
> You are taking this completely out of context.

> The reports I am suggesting, could be linked into the status board your 
> suggesting. So your basically proposing the same thing in a different way.

Right. I suspect we're probably closer to the same page than we think overall,
just your initial statements seemed to give me the wrong subtext, and I wanted
to steer clear away from it.

> Oh yes, create more positions and roles no one wants to fulfill. Are you going 
> to do that? Just another area/project/team to be understaffed. FYI this is 
> what used to happen as part of the newsletter.

There will still be a person or persons submitting data, and there will
be a person or persons receiving and collating that data.

All my framing concerns itself with is assigning the responsibility for this
interaction towards the recipient, and making it clear from the nature of the
interaction that feedback is regularly wanted, but not mandatory.

> > As an adjunct, it might also be useful to have some sort of active "status
> > board" for different projects that can be edited by anyone easily and can
> > easily be displayed in bulk, and not have any real requirements on its
> > frequency of change.  
> 
> That is something that could be programmed into wiki pages for each project 
> tracking commit activity. However it would still not tell you where the 
> project/team is going or information about its activities.

By "displayed in bulk", if I was unclear, the idea was to be able to have a
global "Gentoo Right now" status page where one could just skim-read through
all the given statuses, ( maybe sort them by freshness )

Commit stats could be displayed on the side, but I wouldn't consider them
the most important part of this design, it would just be a bit of polish
on the finished product, mostly because the signal it gives from the overview
of all of gentoo is very weak, and doesn't really tell you much more
than "alive/dead" ( and of course, not all projects even have commit data )

> 
> > And for groups who want to bother to sit down and have meetings,
> > brief outcomes from those meetings could be part of that status board,
> > perhaps with longer contents in links.  
> 
> That is in part what I am suggesting in a report provided to the council.
> 
> The reports I am suggesting, could be linked into the status board your 
> suggesting. So your basically proposing the same thing in a different way.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

On Friday, January 20, 2017 11:21:07 AM EST Kent Fredric wrote:
>
> Right. I suspect we're probably closer to the same page than we think
> overall, just your initial statements seemed to give me the wrong subtext,
> and I wanted to steer clear away from it.

The more you understand the intent and context you will likely find yourself 
more on the same page. Just read the GLEP its pretty simple.

> There will still be a person or persons submitting data, and there will
> be a person or persons receiving and collating that data.

That should be up to each project, ideally the team lead but that is up to 
each. Who in the project creates and submits the report to council is moot.

> All my framing concerns itself with is assigning the responsibility for this
> interaction towards the recipient, and making it clear from the nature of
> the interaction that feedback is regularly wanted, but not mandatory.

I am suggesting projects should have a mandatory requirement to provide 
monthly status. If they meet, they have this already in any minutes or log. 
May require a summation. If they do not meet, someone can gather the info up 
to each project/team. It would take considerably less time for someone on the 
project/team to provide a summary. Than for another person to come poll each 
person in the team for the same information. It will take less time to come 
from within.

I am not suggesting or discussing penalties. I would simply hope that saying 
something is mandatory. People understanding it has VERY minimal requirements 
and overhead. That they would understand the benefit and be onboard so its not 
a big deal.

No reason to make it into a big deal and go off on punishment, etc. I hate 
that line of thinking. I rather people understand the benefits and partake 
because of such.

> By "displayed in bulk", if I was unclear, the idea was to be able to have a
> global "Gentoo Right now" status page where one could just skim-read through
> all the given statuses, ( maybe sort them by freshness )

Which again this could feed into that. You will still need some brief info on 
each project. Again easier and more efficient to come from within than poll from 
outside involving more people and time.

> Commit stats could be displayed on the side, but I wouldn't consider them
> the most important part of this design, it would just be a bit of polish
> on the finished product, mostly because the signal it gives from the
> overview of all of gentoo is very weak, and doesn't really tell you much
> more than "alive/dead" ( and of course, not all projects even have commit
> data )

Commits show activity but not much more. Thus you need to speak to someone or 
have them provide information on what they and others they work with have been 
up to. It is not much.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Patrick McLean]

On Thu, 19 Jan 2017 17:50:38 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > All my framing concerns itself with is assigning the responsibility
> > for this interaction towards the recipient, and making it clear
> > from the nature of the interaction that feedback is regularly
> > wanted, but not mandatory.  
> 
> I am suggesting projects should have a mandatory requirement to
> provide monthly status. If they meet, they have this already in any
> minutes or log. May require a summation. If they do not meet, someone
> can gather the info up to each project/team. It would take
> considerably less time for someone on the project/team to provide a
> summary. Than for another person to come poll each person in the team
> for the same information. It will take less time to come from within.

This is an all volunteer organization, we should refrain from making
any sort of regular "mandatory" actions. Since no one is paid, we can't
have any specific expectations of when people have time to spend on
Gentoo. I would also have someone with limited time spending their time
working on bugs etc rather than writing a monthly report.

Even at companies, where people are paid to work, engineers are not
generally expected to provide status reports to management. That is
generally the job of a _paid_ project manager or _paid_ manager.

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 4329 bytes --]

On Thursday, January 19, 2017 3:24:23 PM EST Patrick McLean wrote:
>
> This is an all volunteer organization, we should refrain from making
> any sort of regular "mandatory" actions.

I am quite aware. I really do not think the obvious need be stated. Also it is 
a bit ridiculous to think volunteer organizations do not have any sort of 
mandatory requirements on volunteers.

If you volunteer for say the RedCross. They will assign you tasks and duties, 
if not when to show up, etc. Very few volunteer efforts are just show up do 
what ever, when ever. At minimum you will have a time to report, how long you 
will be there, etc. Not to mention leaders and people organizing the tasks.

There are volunteer fire departments. Should they not be required to do 
anything? I think its silly to say a volunteer should not be required to do 
anything.

> Since no one is paid, we can't
> have any specific expectations of when people have time to spend on
> Gentoo.

Some are paid to work on Gentoo in some capacity or another. Others are self 
employed, so their time comes more at a direct cost. Where someone who is 
employed would be doing it in their spare time outside of their paying job. 
Others may be students etc. I have seen many people use it on resumes and 
further their career. Acting like people have no personal benefit or interest 
is also silly.

Now I am not suggesting it be done on any mandatory schedule. If a project 
leader or member cannot take ~5-10 minutes a month to inform say the world. 
Then I think that reflects more on their own time management. This is not 
really asking much. Nor would it require much time at all.

Council members are expected to meet, etc. That is much more of a time 
requirement. Requiring projects to report is minimal. Trivial if they have 
monthly meetings.

> I would also have someone with limited time spending their time
> working on bugs etc rather than writing a monthly report.

If bugs could be fixed in 5-10 minutes, I think most would not exist. Many tend 
to require more time. Also tremendous time was spent before on the GWN. This 
is subsets of data that was in that. Which could really help others say on the 
News project. Allowing them to spend less time on getting pertinent data. What 
you may see as a loss of time and focus. Can also be beneficial to other 
projects saving them time, and allow more bugs to get fixed, etc.

Your also missing entire that such reporting can help people outside of Gentoo 
gain more interest in Gentoo. If they know what is going on. You want bugs 
fixed? Would more people not potentially mean more bugs are fixed faster? Or 
rather expect more time from the existing pool?

This is in part to grow Gentoo.

> Even at companies, where people are paid to work, engineers are not
> generally expected to provide status reports to management. That is
> generally the job of a _paid_ project manager or _paid_ manager.

I am not imposing that leaders be required for such. But leaders once upon a 
time in Gentoo were called managers. Is there really a problem with asking 
leaders to inform other leaders? How is the council supposed to know what is 
going on in each project otherwise? How can the council make any global 
decisions without global information?

That said projects are already required to do things now.

"A project exists if it has a maintained Wiki project page as described below. 
("Maintained" means that the information on the page is factually correct and 
not out-of-date.) If the Wiki page isn't maintained, it is presumed dead."
https://wiki.gentoo.org/wiki/GLEP:39

That could be saying that if the wiki page is not maintained the wiki page is 
dead. However that it starts with saying a project exists if it has a 
maintained wiki page. Makes it clear that it is mandatory to maintain a wiki 
page or the project is presumed dead.

Maintaining a project wiki page is in a sense a form of reporting. A project 
page is not necessary technical documentation and very few provide technical 
information. Project pages serve as information on the project, its members, 
duties etc. Thus projects already have mandatory requirements.

Such reporting could be used and part of a projects home page which would help 
the project meet its requirements under GLEP 39. 

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Thu, 19 Jan 2017 21:45:13 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> Your also missing entire that such reporting can help people outside of Gentoo 
> gain more interest in Gentoo. If they know what is going on. You want bugs 
> fixed? Would more people not potentially mean more bugs are fixed faster? Or 
> rather expect more time from the existing pool?
> 
> This is in part to grow Gentoo.

I'm ok with some plan having a fringe benefit of increasing public awareness.

I just want to make sure this is not a primary objective.

Popularity through a reputation of quality is preferred over attempting to gain
quality through a reputation of popularity.

The latter does make you grow faster, but I have no interest in something popular
but substandard, which usually happens.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1694 bytes --]

On 01/20/2017 05:11 PM, Kent Fredric wrote:
> On Thu, 19 Jan 2017 21:45:13 -0500
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> 
>> Your also missing entire that such reporting can help people outside of Gentoo 
>> gain more interest in Gentoo. If they know what is going on. You want bugs 
>> fixed? Would more people not potentially mean more bugs are fixed faster? Or 
>> rather expect more time from the existing pool?
>>
>> This is in part to grow Gentoo.
> 
> I'm ok with some plan having a fringe benefit of increasing public awareness.
> 
> I just want to make sure this is not a primary objective.
> 
> Popularity through a reputation of quality is preferred over attempting to gain
> quality through a reputation of popularity.
> 
> The latter does make you grow faster, but I have no interest in something popular
> but substandard, which usually happens.
> 
Agreed. If there's interest in growing Gentoo, it should be Gentoo
developers who care enough about it to do something, like maffblaster
who started/resurrected the gentoo-news project. *That* is something
that could engage the community and keep people up-to-date on what's
going on. Naturally, it'll need more developers to be involved, but
every large thing started out small, so it has tons of room to grow.

Making this thing or that thing mandatory adds to the already protracted
processes of our structure. It's an idea that sounds good in general but
when applied to our context (non-profit, volunteer work), it doesn't work.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Saturday, January 21, 2017 11:27:49 PM EST Daniel Campbell wrote:
>
> 
> Agreed. If there's interest in growing Gentoo, it should be Gentoo
> developers who care enough about it to do something,

Then why isn't Gentoo growing? For a very long time now.

This attitude that Gentoo is its developers is VERY wrong. There is allot that 
comes from the community. Most developers started as members of the community.

Gentoo developers are NOT the only ones who do the work. They are not the only 
ones who care, and at times some would say they are the ones allowing neglect.
Gentoo Developers have a proven track record of only carrying about things 
that are of interest to them. NOT Gentoo over all, big difference.

> like maffblaster
> who started/resurrected the gentoo-news project. *That* is something
> that could engage the community and keep people up-to-date on what's
> going on.

Yes as it did before and the GWN and even monthly ended for a reason.

> Naturally, it'll need more developers to be involved, but
> every large thing started out small, so it has tons of room to grow.

Really interesting how you start with saying it will take developers, then end 
with saying it needs more developers..

> Making this thing or that thing mandatory adds to the already protracted
> processes of our structure. It's an idea that sounds good in general but
> when applied to our context (non-profit, volunteer work), it doesn't work.

I like how something not tired is known not to work. Go look around your 
community. Find a non profit or volunteer somewhere. See if you are not 
required to do stuff.

People need to get past this volunteer npo BS. It is an excuse not reality!!!

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 10374 bytes --]

On 01/22/2017 08:27 AM, William L. Thomson Jr. wrote:
> On Saturday, January 21, 2017 11:27:49 PM EST Daniel Campbell wrote:
>>
>>
>> Agreed. If there's interest in growing Gentoo, it should be Gentoo
>> developers who care enough about it to do something,
> 
> Then why isn't Gentoo growing? For a very long time now.
> 
> This attitude that Gentoo is its developers is VERY wrong. There is allot that 
> comes from the community. Most developers started as members of the community.
> 
> Gentoo developers are NOT the only ones who do the work. They are not the only 
> ones who care, and at times some would say they are the ones allowing neglect.
> Gentoo Developers have a proven track record of only carrying about things 
> that are of interest to them. NOT Gentoo over all, big difference.

You're right; Gentoo developers aren't the only ones doing work. The
Gentoo community is similar to other libre software communities in that
they help each other in support channels, they write tutorials and/or
tools for use with the distro, they talk about it in other fora, and
sometimes bring more people to the distro. This produces a lot of
positive for Gentoo, but at the core of it it's only us (the developers)
who can really change Gentoo as an entire distribution. We decide
policy, we decide QA, we decide whether infra stays up. I'm not
advocating that we *abuse* that power, but a common reason we become
developers is that we've proven we can contribute positively to Gentoo
and know enough about the structure to know how things get done, even if
it's a process we don't agree with. That's a hassle for some people, and
I fully understand that.

On the matter of only working on things that interest us, I think that's
slightly too simplistic. It's natural to work on things that interest
us, but that's coupled with an attitude of safety. I can't speak for
other developers, but I don't want to work on something I'm not
knowledgeable and competent in. What little time I get to devote to
Gentoo, I'd rather contribute in ways that I'm (more) competent in, so I
don't create more work for others. Naturally, that's going to look like
someone's avoiding work, but the "why" really matters here. I get the
feeling that I'm not alone in that sentiment. Now, that also means I
might not learn as much as I could. I think I'd be hurting Gentoo if I
used it as my personal self-education without respect for the processes
and practices that allowed Gentoo -- and by extension my developer-hood
-- to be possible. So that's why a safety-first approach to things
generally works for collaborative environments. It slows things down,
yes. But it also tends to break a little less often as a result. If that
style doesn't match with someone, that someone would be happier and more
productive in another distro or another project type entirely (one that
doesn't have such myriad requirements for interoperability and technical
compatibility -- things that an OS needs to care about).

If the community takes matters into its own hands and decides they'll be
the face of Gentoo, well... legally they can't do that. The foundation
owns the trademark. But they can fork it, and many have. Some believe
that's reason for concern. In some ways they're right: it *should* be a
little concerning to learn when we get a new fork, because it shows us
that there's a problem with Gentoo -- one so great that somebody said,
"screw it, I'll make my own, with blackjack and hookers." [0] We should
be seeking these forks and learning from them, so that -- if the
reasoning behind a given fork is compelling to our interests -- we can
either find a way to work better with that fork, or change things so
that a fork isn't necessary in the first place. The recent RFC
concerning distribution variables from Galapagos Linux is an example of
ways we can work *with* our forks rather than against them.

Forking in general isn't necessarily a bug, though. It's as much a
feature of libre software as libre licenses are, and is the foundation
of the Bazaar model. Those that make up a group need to be able to
maintain their work should the fish start rotting from the head, so to
speak. So with that said, please don't interpret my words as being
against forks. I think they're good, and sometimes necessary. But we can
and should learn from them where possible.

> 
>> like maffblaster
>> who started/resurrected the gentoo-news project. *That* is something
>> that could engage the community and keep people up-to-date on what's
>> going on.
> 
> Yes as it did before and the GWN and even monthly ended for a reason.

What reason do you think that is? Not meant to be sarcastic; I'm
honestly interested. We should discuss that in a different thread,
however, so please feel free to open a new one or find the Gentoo News
thread, where that may be more relevant.

> 
>> Naturally, it'll need more developers to be involved, but
>> every large thing started out small, so it has tons of room to grow.
> 
> Really interesting how you start with saying it will take developers, then end 
> with saying it needs more developers..

Well, you're right, adding more people to a project doesn't
automatically fix things. It comes with project management overhead,
even more people who aren't on the same page, etc. Adding mandatory
reporting could throw a serious wrench into our workflows, because we
already have trouble getting developers to run repoman or other helpful
tools that assist us in producing a better distribution, or OpenPGP key
compliance, signed manifests and commits, etc.

In short, there's no shortage of problems to fix within Gentoo, and
holding that back with what amounts to paperwork isn't going to fix it.
The work itself needs to be done. Direction for said work is important,
too, which is why Gentoo has a metastructure that allows for projects
and the leads for those projects. Assuming a project isn't violating QA
guidelines/policy and isn't causing a ton of work for others, they're
pretty much free to govern how they see fit. Most from what I can tell
are very informal, to facilitate simple and clear communication. I think
what you're advocating for is really just better leadership. Gentoo
won't get that until we get people who want to lead and care enough
about Gentoo to make it happen. We need to vote people in who we believe
see enough of the big picture to kinda nudge things in the right
direction, but enough gritty details to make educated decisions when the
vote on agenda minutes or make judgment calls on disputes.

That's all Gentoo-land stuff, however. It's stuff that the community on
its own doesn't have the power to do. So it comes down to us and the
people we vote in. If our metastructure is suffering, if recruitment is
down, if we're not on top of things, blame lies squarely with us, the
developers. We should be more conscientious in our voting and look for
ways to improve our wetware when possible. But that must be tempered
with real work, too. What good is electing someone if they don't do what
they say? What use is it to become a developer if you then do nothing?
(note: I'm semi-guilty of that at times)

I guess what I'm saying is words and actions should go together. When
they don't we should fix it. We don't need weeks-long discussions stuck
in analysis paralysis. If it's important, write an RFC, get it on the
agenda, and have people make decisions on it. It's what they were voted
in for, after all. In my limited experience with things like that, I've
learned that if someone makes a lot of noise about something but doesn't
back it up with a proposed solution (RFC) and real action (bringing it
before council to vote), then maybe that person didn't care enough. I've
been guilty of that, too, mostly when I was using other distributions. I
learned a lot when I became a dev here, and most of it boils down to
age-old wisdom: actions speak louder than words.
> 
>> Making this thing or that thing mandatory adds to the already protracted
>> processes of our structure. It's an idea that sounds good in general but
>> when applied to our context (non-profit, volunteer work), it doesn't work.
> 
> I like how something not tired is known not to work. Go look around your 
> community. Find a non profit or volunteer somewhere. See if you are not 
> required to do stuff.
> 
> People need to get past this volunteer npo BS. It is an excuse not reality!!!
> 

With that logic, we should try literally every metastructure or
policy-set possible before we settle on one that works Good Enough™.
Perfect is the enemy of good, after all.

Requirements in the physical world are applied in a different manner
because it is separate from the digital world. Reporting requirements
and other bureaucracy work in in-person organizations that have clear
and distinct goal. Our work in general is to develop and maintain
Gentoo, which means different things to different people. So rather than
adopt a strict process, groups are allowed to form and disperse
naturally and informally. This is inefficient if the goal is to get as
much development done as possible, but it's much more efficient for
*humans*. Too much order and control is mechanical; not enough is a
free-for-all. There's no harm in letting developers work on what they
find interesting. For the gaps, it's a sign that we need to find people
who enjoy Gentoo enough and are knowledgeable enough in those
categories, and see if they're up for becoming developers.

That's not *required*, however, because git is a thing. Someone who
wants to help Gentoo generally *can*. Nothing related to our processes
stops a person from `git pull`ing, hacking, and contacting a developer
to get something put in. We credit contributions, too. The project needs
*some* sort of gate keepers to watch over the infra and primary
development. Naturally, these people are called developers.

tldr: Mandatory reporting == paperwork, and is unneeded overhead.

[0] I hope it's obvious this particular quote is a joke, but you can't
be too sure over text.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Thu, 19 Jan 2017 15:24:23 -0800
Patrick McLean <chutzpah@gentoo.org> wrote:

> This is an all volunteer organization, we should refrain from making
> any sort of regular "mandatory" actions. Since no one is paid, we can't
> have any specific expectations of when people have time to spend on
> Gentoo. I would also have someone with limited time spending their time
> working on bugs etc rather than writing a monthly report.

Gentoo does have some mandatory expectations of developers.

But these seem to frequently serve as a barrier to development, and such
mandatory controls are typically employed as gate-keepers.

I would rather have only as many of these as is absolutely necessary.

> 
> Even at companies, where people are paid to work, engineers are not
> generally expected to provide status reports to management. That is
> generally the job of a _paid_ project manager or _paid_ manager.

I wish that was true, but like, that's an expectation of a *good* company
that is well run.

But my observation is too few companies meet any definition of "good".

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Dean Stephens]

On 01/19/17 17:50, William L. Thomson Jr. wrote:
> I am suggesting projects should have a mandatory requirement to provide 
> monthly status. If they meet, they have this already in any minutes or log. 
> May require a summation. If they do not meet, someone can gather the info up 
> to each project/team. It would take considerably less time for someone on the 
> project/team to provide a summary. Than for another person to come poll each 
> person in the team for the same information. It will take less time to come 
> from within.
> 
> I am not suggesting or discussing penalties. I would simply hope that saying 
> something is mandatory. People understanding it has VERY minimal requirements 
> and overhead. That they would understand the benefit and be onboard so its not 
> a big deal.
> 
> No reason to make it into a big deal and go off on punishment, etc. I hate 
> that line of thinking. I rather people understand the benefits and partake 
> because of such.
> 
Just to point out, part of, why people are interpreting this as they
are: you frame it as a requirement, even a "mandatory requirement",
without specifying what recourse, if any, there is if such requirements
are not met. This implicitly leaves the default mechanisms in place, as
has been discussed elsewhere. A requirement with no enforcement,
especially one which explicitly avoids enforcement is a suggestion, or
request, not a requirement.

Not that I find no other faults with the proposal as a whole.

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Friday, January 20, 2017 10:27:34 PM EST Dean Stephens wrote:
>
> Just to point out, part of, why people are interpreting this as they
> are: you frame it as a requirement, even a "mandatory requirement",
> without specifying what recourse, if any, there is if such requirements
> are not met. 

I can understand that perspective. I am more of the mindset of not having 
recourse. I am not a fan of punishment. If projects repeatedly do not do it, 
oh well. That is their choice, just not encouraged.

> This implicitly leaves the default mechanisms in place, as
> has been discussed elsewhere. A requirement with no enforcement,
> especially one which explicitly avoids enforcement is a suggestion, or
> request, not a requirement.

By stating mandatory the idea is to encourage it to be considered something 
that should be done and not ignored. I would think non-compliance to be more 
egg on face of leaders or members. Not a punishable offense.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3344 bytes --]

On 01/21/2017 12:12 AM, William L. Thomson Jr. wrote:
> On Friday, January 20, 2017 10:27:34 PM EST Dean Stephens wrote:
>>
>> Just to point out, part of, why people are interpreting this as they
>> are: you frame it as a requirement, even a "mandatory requirement",
>> without specifying what recourse, if any, there is if such requirements
>> are not met. 
> 
> I can understand that perspective. I am more of the mindset of not having 
> recourse. I am not a fan of punishment. If projects repeatedly do not do it, 
> oh well. That is their choice, just not encouraged.
> 
>> This implicitly leaves the default mechanisms in place, as
>> has been discussed elsewhere. A requirement with no enforcement,
>> especially one which explicitly avoids enforcement is a suggestion, or
>> request, not a requirement.
> 
> By stating mandatory the idea is to encourage it to be considered something 
> that should be done and not ignored. I would think non-compliance to be more 
> egg on face of leaders or members. Not a punishable offense.
> 

And let's take a very rigorous look back at this, since there seems to
be a lack of uniformity in opinions.

Definition(Requirement):a thing that is compulsory; a necessary condition.
Definition(Compulsory):required by law or a rule; obligatory
Definition(Obligatory):required by a legal, moral, or other rule; compulsory

OK, so clearly, these are circular.  The point is, a requirement, is
compulsory and obligatory, ie you MUST do it, you are obligated, you are
compelled to do so.  But if you are told that you MUST do it, what
happens if you opt not to?  Well, one of two things, action must be
undertaken to FORCE that behavior, or inaction allows that behavior to
continue.  If the former, one of two things may happen, positive
reinforcement, or negative reinforcement.  Positive reinforcement would
most likely be things like a paycheck, you do your work, you get paid.
Negative reinforcement is obviously punishment of some sort. If we are
talking about the latter, inaction, the original condition is not being
forced.  Thus, it is not a REQUIREment as the individual is NOT REQUIRED
to perform said action.

Now, that takes us back to the points made by everyone else in this
thread...  All of which are stating that they do not want compulsory
reporting actions, in part, because they don't like the premise of being
punished for failure to perform such an activity.

If you concede that you didn't intend to say compulsory, must do lest
the person/project incur a punishment, then we aren't talking about
requirements, we are talking about a suggestion.

I hardly think anyone would complain at the suggestion of projects
voluntarily reporting to the council for updates if they so wish, and
that it might be useful for council to poke projects to remind them that
they may exercise that right if they so choose.

If your goal is to impose compulsory behavior that goes beyond QA and
other similar necessities of development, I suspect that you will find
almost no support anywhere.  As cited before in this thread, we aren't
paid to put up with requirements, there is no positive reinforcement,
only negative reinforcement, so adding barriers to contributions is
ill-advised and will not be well received.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 4238 bytes --]

On Saturday, January 21, 2017 12:30:35 AM EST NP-Hardass wrote:
>
> OK, so clearly, these are circular.  The point is, a requirement, is
> compulsory and obligatory, ie you MUST do it, you are obligated, you are
> compelled to do so.  But if you are told that you MUST do it, what
> happens if you opt not to? 

Again this is no about punishment. People are focusing to much on what if I do 
not do the report... Rather than hey that is a good idea, we should see that 
it is done.
 
> Now, that takes us back to the points made by everyone else in this
> thread...  All of which are stating that they do not want compulsory
> reporting actions, in part, because they don't like the premise of being
> punished for failure to perform such an activity.

People have the idea that since they are a volunteer nothing should be 
required of them. They should be able to do what ever, work on what ever, when 
ever, how ever they feel like it. Any attempt to bring about organization 
tends to meet resistance with many "excuses" as to why not.
 
> If you concede that you didn't intend to say compulsory, must do lest
> the person/project incur a punishment, then we aren't talking about
> requirements, we are talking about a suggestion.

People need to stop focusing on punishment. If all comply no need, so 
discussions on such are futile and a waste of time.

It is not about punishment. It is clarifying what is expected, just do it, 
nothing to punish or discuss.

> I hardly think anyone would complain at the suggestion of projects
> voluntarily reporting to the council for updates if they so wish, and
> that it might be useful for council to poke projects to remind them that
> they may exercise that right if they so choose.

Problem with voluntary is it does not create any sort of pressing need. If 
they understand they are required, there is a pressing need. It should not 
require punishment for compliance. It is voluntary to do such reporting now. 
Are projects producing voluntary reports now?

If intelligent people cannot understand the benefit of spreading around 
information.  That is their own personal issue. This should make sense to 
anyone, and be like news from each project. Anyone not wanting to inform 
others of activity in their project. Sounds more like secrecy, or childish I 
do not want to be bothered with that or informing others. Rather than a lack 
of time or solid reason. It does not take much!

Part of the point of FOSS is having free access to the information, source 
code. Thus we should have free access to activity just the same.

> If your goal is to impose compulsory behavior that goes beyond QA and
> other similar necessities of development, I suspect that you will find
> almost no support anywhere.  As cited before in this thread, we aren't
> paid to put up with requirements, there is no positive reinforcement,
> only negative reinforcement, so adding barriers to contributions is
> ill-advised and will not be well received.

Again anytime anyone makes attempts at organization there is heavy blow back. 
Though other distros do place requirements, and not discuss punishment.

"A big part of your job as Debian maintainer will be to stay in contact with 
the upstream developers. Debian users will sometimes report bugs that are not 
specific to Debian to our bug tracking system. You have to forward these bug 
reports to the upstream developers so that they can be fixed in a future 
upstream release."
https://www.debian.org/doc/manuals/developers-reference/ch03.en.html

That seems like a pretty hard requirement to me. They say it is part of your 
"job" and you "have" to forward stuff to upstream. That sounds pretty 
mandatory, obligatory, what ever word you want to use, etc.

What happens if as a Debian developer you NEVER provide anything to upstream? 
Their documentation does not cover such. People focus to much on punishment.

If the word "job" was used around Gentoo, the crap would hit the fan. The 
Gentoo community seems to have serious issues with organization for a 
volunteer project. Many volunteers have bosses, duties, responsibilities, 
requirements, etc.

The comments thus far reflect more an attitude issue than policy.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 432 bytes --]

On 01/21/2017 07:04 AM, William L. Thomson Jr. wrote:
> People are focusing to much on what if I do 
> not do the report... Rather than hey that is a good idea, we should see that 
> it is done.

That's a legitimate concern, because policies are nothing without
enforcement.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Sat, 21 Jan 2017 00:12:57 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> > Just to point out, part of, why people are interpreting this as they
> > are: you frame it as a requirement, even a "mandatory requirement",
> > without specifying what recourse, if any, there is if such requirements
> > are not met.   
> 
> I can understand that perspective. I am more of the mindset of not having 
> recourse. I am not a fan of punishment. If projects repeatedly do not do it, 
> oh well. That is their choice, just not encouraged.

I think that's possibly what confused me.

Terms like "Promoted", "Encouraged", "Recommended" are probably closer
to your perspective in that they convey being "Very strong indications that
a thing should be done", instead of "An indication a thing _must_ be done".

Because indicating _must_ does imply definitive actionable consequences for
non-compliance.

Where's the others only imply that somebody might bend your arm and give you
a conversation if compliance is not met.

And then you can term the failure to comply as an opposite:

"Neglecting to report is strongly discouraged"

Whereas if you say "mandatory"/"must", then the opposites are

"must not", and "forbidden"






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Sunday, January 22, 2017 4:53:24 AM EST Kent Fredric wrote:
> On Sat, 21 Jan 2017 00:12:57 -0500
> 
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > > Just to point out, part of, why people are interpreting this as they
> > > are: you frame it as a requirement, even a "mandatory requirement",
> > > without specifying what recourse, if any, there is if such requirements
> > > are not met.
> > 
> > I can understand that perspective. I am more of the mindset of not having
> > recourse. I am not a fan of punishment. If projects repeatedly do not do
> > it, oh well. That is their choice, just not encouraged.
> 
> I think that's possibly what confused me.

Yes because the attitude around here is one of punishment rather than 
encouragement. If someone is misbehaving, punish rather than encourage to 
behave different. Things are very twisted IMHO.

If a project fails to report, punish rather than help. I rather help!

> Terms like "Promoted", "Encouraged", "Recommended" are probably closer
> to your perspective in that they convey being "Very strong indications that
> a thing should be done", instead of "An indication a thing _must_ be done".

Yes but then makes it more optional. It is best if people consider it 
something that must be done. Then others will hopefully help out if not done.

> Because indicating _must_ does imply definitive actionable consequences for
> non-compliance.

My idea of consequences is very different. For example say a project cannot 
report. The council notices this and inquires with the project. How can we 
help? Do you need staff? Are you unable to do the report just this month or 
every? Where can we help?

I look at non-compliance as more a friendly thing than malicious. Thus should 
be friendly in helping to comply.

> Where's the others only imply that somebody might bend your arm and give you
> a conversation if compliance is not met.

Yes because there is a horrible atmosphere and attitude around Gentoo these 
days. I am not of that mindset or perspective. I never have been.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Sat, 21 Jan 2017 12:03:02 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> Yes because there is a horrible atmosphere and attitude around Gentoo these 
> days. I am not of that mindset or perspective. I never have been.

That may be how you see it.

But for me, I don't really have that problem in general, and I only seem to bump
into it when dealing with these horrible mailinglists of rivers of emails that
never end, when I'd rather STFU&WSC

And for me, it very much *is* what you're writing that gives me these vibes.

I don't pretend to be able to explain how that is, but it is true.

I don't know how to resolve it either, but I'm just generally trying to think
to myself "Should I actually respond, or should I just shut my mouth and do
something else lest I make this fire worse"

But like, I think I'm sweating petrol lately and everyone else is getting
sick of the heat.

-- Returning to the STFU&WSC pattern.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Thursday, January 26, 2017 2:57:12 PM EST Kent Fredric wrote:
> On Sat, 21 Jan 2017 12:03:02 -0500
> 
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > Yes because there is a horrible atmosphere and attitude around Gentoo
> > these
> > days. I am not of that mindset or perspective. I never have been.
> 
> That may be how you see it.

No that is fact, given how people keep discussing and focusing on punishment.
It clearly shows a mindset and the atmosphere. Not a friendly one!

> But for me, I don't really have that problem in general, and I only seem to
> bump into it when dealing with these horrible mailinglists of rivers of
> emails that never end, when I'd rather STFU&WSC

Please I tend to be more active than most speaking
https://github.com/wltjr

> And for me, it very much *is* what you're writing that gives me these vibes.

You do not know me, and you are reading things I did not write. Worrying about 
things I am not even discussing. None of that comes from me....

> I don't pretend to be able to explain how that is, but it is true.
> 
> I don't know how to resolve it either, but I'm just generally trying to
> think to myself "Should I actually respond, or should I just shut my mouth
> and do something else lest I make this fire worse"

I see allot of people talking who became developers years after I was one. I 
do not see any respect for those that came before. No respect for wisdom 
gained over a decade, etc.

I routinely will google Gentoo New Developer, with a persons name. Rarely am I 
talking to anyone from say before 2010. Most have become developers since and 
have a very different perspective.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 4825 bytes --]

On Thu, 26 Jan 2017 10:45:50 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:

> On Thursday, January 26, 2017 2:57:12 PM EST Kent Fredric wrote:
> > On Sat, 21 Jan 2017 12:03:02 -0500
> > 
> > "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:  
>  [...]  
> > 
> > That may be how you see it.  
> 
> No that is fact, given how people keep discussing and focusing on punishment.
> It clearly shows a mindset and the atmosphere. Not a friendly one!

That's why I'm *only* getting that impression around you. Right.

The reality with human communication, is if people collectively interpret you incorrectly,
that's something only you can rectify. 

It sucks to have people misunderstand you, but you don't get to say
"no, I'm not giving this perception, you're just imagining it"

Because you are giving that perception. It becomes a question of *why* you're giving that perception
and what you can do to rectify that.

Granted, when a perception is misunderstood, you can then subsequently, with care, correct that.

But as to how initial misperceptions are created, that's an exercise that requires your investment.

Nobody else can do it for you.

Related concept presented comically by Louis CK: https://www.youtube.com/watch?v=18y6vteoaQY&t=110

> > But for me, I don't really have that problem in general, and I only seem to
> > bump into it when dealing with these horrible mailinglists of rivers of
> > emails that never end, when I'd rather STFU&WSC  
> 
> Please I tend to be more active than most speaking
> https://github.com/wltjr

I don't get what you're trying to say here. Its not a dick measuring contest. If you're meaning to
say you do more stuff than I do, and how when I say I'd rather STFU&WSC, that I'm just being rhetorical
about that, allow me: 

https://github.com/kentfredric

I don't know which metrics you're specifically suggesting I see, but I think at least one of those
numbers are comparable. But that's besides the point.

I find lengthy mailinglist discussions exhausting and there's often very very little return on investment,
and usually nothing becomes of any of it, so its just stupid conflict without utility. Great.

The only reason I involve myself in the first place is some conflicted deluded side effect of
empathy kicking in. Because somehow, I feel that maybe I can contribute something that will make
a bad situation better. Sometimes my patience helps me here, but usually it just makes me
incredibly depressed about humanity in general.

Instead, I took what I could from this, and pretty much side stepped the need for any such formalised proposal
by just doing something that could potentially be construed to be useful.

I just simply externalised my mental work queue to somewhere on the wiki so people could see it if they cared,
with no requirements of any kind.

https://wiki.gentoo.org/wiki/User:Kentnl/TODO

Somebody could scrape this, and aggregate it, I don't know, I don't care. Its useful to me as-is, and it could be
useful to somebody else. The problem is solved and I can go do something else.

And within hours, somebody noticed and copied me: 

https://wiki.gentoo.org/wiki/User:Leio/TODO

Self-organising systems are great.

> 
> > And for me, it very much *is* what you're writing that gives me these vibes.  
> 
> You do not know me, and you are reading things I did not write. Worrying about 
> things I am not even discussing. None of that comes from me....
> 
> > I don't pretend to be able to explain how that is, but it is true.
> > 
> > I don't know how to resolve it either, but I'm just generally trying to
> > think to myself "Should I actually respond, or should I just shut my mouth
> > and do something else lest I make this fire worse"  
> 
> I see allot of people talking who became developers years after I was one. I 
> do not see any respect for those that came before. No respect for wisdom 
> gained over a decade, etc.
> 
> I routinely will google Gentoo New Developer, with a persons name. Rarely am I 
> talking to anyone from say before 2010. Most have become developers since and 
> have a very different perspective.

There is some kind of respect for people over time, but it plateaus quickly, and beyond
that, everyone are just as mortal and fallible as I am, and they need to prove themselves.

And constantly.

People do change, and sometimes they change for the worse, so being experienced and older
is not in itself an extended license of authority.

One can still respect and listen to those views, but are still entitled to reject them.

I really wish I'd gotten paid for all the times I'd had to babysit people older than me
when they were throwing their toys out of the proverbial cot like children.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]