Thread: Show list of Commitfest Managers
Hello,
Attached patch (based on a discussion we had in a group a few weeks ago)
adds the ability to add name and email address of every Commitfest Manager
to the CF website. It was discussed that it should be shown who runs or ran
a specific CF, and contributed to the success of every cycle.
If the data is available for a specific CF, it will be shown:
- in the CF list on the home page
- in an extra line on the CF page
There is also specific page added which lists all CF and managers.
The patch is an initial draft, open for discussion.
Regards,
-- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project
Attachment
On 3/22/22 1:50 AM, Andreas 'ads' Scherbaum wrote: > > Hello, > > Attached patch (based on a discussion we had in a group a few weeks ago) > adds the ability to add name and email address of every Commitfest Manager > to the CF website. It was discussed that it should be shown who runs or ran > a specific CF, and contributed to the success of every cycle. > > > If the data is available for a specific CF, it will be shown: > > * in the CF list on the home page > * in an extra line on the CF page > > > There is also specific page added which lists all CF and managers. > > The patch is an initial draft, open for discussion. Why do this instead of link to a wiki page? Editing the wiki would be a lower barrier to maintaining this. Jonathan
Attachment
On 22/03/2022 14:41, Jonathan S. Katz wrote:
> On 3/22/22 1:50 AM, Andreas 'ads' Scherbaum wrote:
>>
>> Hello,
>>
>> Attached patch (based on a discussion we had in a group a few weeks ago)
>> adds the ability to add name and email address of every Commitfest
>> Manager
>> to the CF website. It was discussed that it should be shown who runs
>> or ran
>> a specific CF, and contributed to the success of every cycle.
>>
>>
>> If the data is available for a specific CF, it will be shown:
>>
>> * in the CF list on the home page
>> * in an extra line on the CF page
>>
>>
>> There is also specific page added which lists all CF and managers.
>>
>> The patch is an initial draft, open for discussion.
>
> Why do this instead of link to a wiki page? Editing the wiki would be
> a lower barrier to maintaining this.
The maintenance "barrier" is really just adding name and email address once
you create the next CF in the Django admin. And you have all the data in
one place.
This patch shows where the Commitfest Manager is, recognizing the huge
amount
of work people doing for this project. And it adds a contact option
right where it
belongs. The additional page is a nice touch and can be left out, but it
does not
hurt to have it.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
On 3/22/22 1:18 PM, Andreas 'ads' Scherbaum wrote: > On 22/03/2022 14:41, Jonathan S. Katz wrote: >> Why do this instead of link to a wiki page? Editing the wiki would be >> a lower barrier to maintaining this. > > The maintenance "barrier" is really just adding name and email address once > you create the next CF in the Django admin. And you have all the data in > one place. More that a few people manage the pgweb content vs. the entire community manages the wiki. > This patch shows where the Commitfest Manager is, recognizing the huge > amount > of work people doing for this project. And it adds a contact option > right where it > belongs. The additional page is a nice touch and can be left out, but it > does not > hurt to have it. In general, I agree with this, but I don't think that a patch to pgweb specific for CFMs is the answer per se. If we were to add something to pgweb, I think it should be broader, i.e. recognize folks on the various teams / groups. For example, what about RMT team members? What about people on teams/committees that are less recognized (e.g. contributors)? This is why I suggest at least starting with a wiki page that lists the CFMs and we can link to there. Or let's move this patch to cover the more general case of recognizing all of the different Project teams. Thanks, Jonathan
Attachment
On 3/22/22 1:55 PM, Jonathan S. Katz wrote: > On 3/22/22 1:18 PM, Andreas 'ads' Scherbaum wrote: >> On 22/03/2022 14:41, Jonathan S. Katz wrote: > >>> Why do this instead of link to a wiki page? Editing the wiki would be >>> a lower barrier to maintaining this. >> >> The maintenance "barrier" is really just adding name and email address >> once >> you create the next CF in the Django admin. And you have all the data >> in one place. > > More that a few people manage the pgweb content vs. the entire community > manages the wiki. > >> This patch shows where the Commitfest Manager is, recognizing the huge >> amount >> of work people doing for this project. And it adds a contact option >> right where it >> belongs. The additional page is a nice touch and can be left out, but >> it does not >> hurt to have it. > > In general, I agree with this, but I don't think that a patch to pgweb > specific for CFMs is the answer per se. I read the patch too fast and didn't realize that it targeted the CF app specifically. I apologize. Reviewing this again, I believe we can have multiple CFMs per CF. So this would need to be a one-to-many (or many-to-many, see below) relationship. It would be one-to-many if we do not leverage the existing User model, which contains name/email, or many-to-many if we use User. This could be accomplished in a couple of ways: 1. Stick a ManyToMany field on Commitfest to User 2. Do something similar to the "Committer" model[1] but have it act as a join table e.g. "CommitfestManager" that can point to User and Commitfest. This would change the queries in the views, but would ensure we capture everyone who acts a CFM for a CF. (I'm not a committer on the commitfest2 app, so at best I can review for now). Thanks, Jonathan [1] https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=blob;f=pgcommitfest/commitfest/models.py;hb=HEAD#l14
Attachment
On Wed, Mar 23, 2022 at 3:24 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 3/22/22 1:55 PM, Jonathan S. Katz wrote:
> On 3/22/22 1:18 PM, Andreas 'ads' Scherbaum wrote:
>> On 22/03/2022 14:41, Jonathan S. Katz wrote:
>
>>> Why do this instead of link to a wiki page? Editing the wiki would be
>>> a lower barrier to maintaining this.
>>
>> The maintenance "barrier" is really just adding name and email address
>> once
>> you create the next CF in the Django admin. And you have all the data
>> in one place.
>
> More that a few people manage the pgweb content vs. the entire community
> manages the wiki.
>
>> This patch shows where the Commitfest Manager is, recognizing the huge
>> amount
>> of work people doing for this project. And it adds a contact option
>> right where it
>> belongs. The additional page is a nice touch and can be left out, but
>> it does not
>> hurt to have it.
>
> In general, I agree with this, but I don't think that a patch to pgweb
> specific for CFMs is the answer per se.
I read the patch too fast and didn't realize that it targeted the CF app
specifically. I apologize.
Reviewing this again, I believe we can have multiple CFMs per CF. So
this would need to be a one-to-many (or many-to-many, see below)
relationship. It would be one-to-many if we do not leverage the existing
User model, which contains name/email, or many-to-many if we use User.
This could be accomplished in a couple of ways:
1. Stick a ManyToMany field on Commitfest to User
2. Do something similar to the "Committer" model[1] but have it act as a
join table e.g. "CommitfestManager" that can point to User and Commitfest.
This would change the queries in the views, but would ensure we capture
everyone who acts a CFM for a CF
Yes, we can have more than one. And in either case storing a copy of an email that's not being updated, is a bad idea.
it definitely seems better with (2) of your choices above. There may be other things that we want to add to this relationship in the future.
And it should probably also utilize the UserProfile model and make it possible for the CFM to choose which email address they should be referred by. Several people who originally requested the ability to user a separate email are amongst the ones who have been CF managers.
On 28/03/2022 18:15, Magnus Hagander wrote:
On Wed, Mar 23, 2022 at 3:24 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:On 3/22/22 1:55 PM, Jonathan S. Katz wrote:
> On 3/22/22 1:18 PM, Andreas 'ads' Scherbaum wrote:
>> On 22/03/2022 14:41, Jonathan S. Katz wrote:
>
>>> Why do this instead of link to a wiki page? Editing the wiki would be
>>> a lower barrier to maintaining this.
>>
>> The maintenance "barrier" is really just adding name and email address
>> once
>> you create the next CF in the Django admin. And you have all the data
>> in one place.
>
> More that a few people manage the pgweb content vs. the entire community
> manages the wiki.
>
>> This patch shows where the Commitfest Manager is, recognizing the huge
>> amount
>> of work people doing for this project. And it adds a contact option
>> right where it
>> belongs. The additional page is a nice touch and can be left out, but
>> it does not
>> hurt to have it.
>
> In general, I agree with this, but I don't think that a patch to pgweb
> specific for CFMs is the answer per se.
I read the patch too fast and didn't realize that it targeted the CF app
specifically. I apologize.
Reviewing this again, I believe we can have multiple CFMs per CF. So
this would need to be a one-to-many (or many-to-many, see below)
relationship. It would be one-to-many if we do not leverage the existing
User model, which contains name/email, or many-to-many if we use User.
This could be accomplished in a couple of ways:
1. Stick a ManyToMany field on Commitfest to User
2. Do something similar to the "Committer" model[1] but have it act as a
join table e.g. "CommitfestManager" that can point to User and Commitfest.
This would change the queries in the views, but would ensure we capture
everyone who acts a CFM for a CFYes, we can have more than one. And in either case storing a copy of an email that's not being updated, is a bad idea.it definitely seems better with (2) of your choices above. There may be other things that we want to add to this relationship in the future.And it should probably also utilize the UserProfile model and make it possible for the CFM to choose which email address they should be referred by. Several people who originally requested the ability to user a separate email are amongst the ones who have been CF managers.
That's useful feedback, thank you.
Will find time and rework this.
Last question: keep the separate list of CFM, or "just" add the CFM after every CF on the main page?
Regards,
-- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project