Creating a maintainer-contributor feedback loop

[tim-schilling]

Ideally a package would exist that could communicate news about Django and relevant packages to users. By default it's just public information and DjangoCon conferences. Maybe some subset of the djangoproject.com blog?

If users want tailored results, they can browse to a site where they'd create an account, select their preferences and be provided an API token. That would then fetch tailored information. Theoretically this could be done entirely anonymously.

Some ideas of messages that could be shared:

• maintainers wanted
• elections
• discussions
• surveys
• announcements for projects in repo

Some ideas on where the messages could be presented to the user:

• pre-commit
• runserver
• once per week, but configurable client side
• integrate with the admin

It's possible to do this entirely without a user token, but that does make it easier to manage rate limiting and provides abilities for more explicit communication (DSF members info?) that folks could opt into.

[oliverandrich]

Help me to understand your idea. Will these announcements only cover the project I am currently dealing with? Or will I see a general news feed covering all kinds of tools?

Let's take pre-commit. If I run pre-commit in one of my projects and one of the dependencies wants to share information with me like “Maintainers searched.”, announcements and so on. I would be fine with it. But if any run of pre-commit informed me about the next DSF or PSF election, or other, at this moment, completely unrelated information, I would immediately search for a way to disable it.

Did I get what your idea is?

[tim-schilling]

It'd start with DSF news because that the most relevant to django developers and it's fairly infrequent.

In my ideal vision, there'd be a way for any package maintainer to define their own news that could be relayed to users.

You understood the correct components, but maybe not the configuration of them.

[oliverandrich]

Thanks for the clarification. If I as a maintainer can configure this, I am fine with the idea. And I agree, infrequent news like the one from the DSF is a good idea. I was a bit afraid that my terminal will turn into a news feed. :)

[nanorepublica]

Not news, but one source of inspiration would be to look at the history of the npm fund command which lists the sponsorship page for dependencies in a project which includes transitive dependencies.

I would be plus one on having it in the admin over other locations. Mainly as this could bring other users of the admin into the community, it would be fairly easy to customize & extend as most django devs ought to be able to write some templates, and personally I think it would fix best into my work cycle. I think I would miss the information in the other places.

[tim-schilling]

I hadn't thought of templates. I was thinking of having yaml, json or markdown. Something that's a bit easier to parse and more human readable.

Maybe a html template allows a person to be more creative?

[nanorepublica]

My initial thought was that it would be an additional actions box to the admin homepage. Some well defined blocks would allow any package to call {{ super }} and then add their bits (with in reason). This could also link out to other custom pages or external URLs easily - maybe even forms in the future?

[tim-schilling]

Ah gotcha. I hadn't thought about forms. That's an interesting take. Personally, I think we'd want a more structured form of data so it's easier to process/analyze later on.

[nanorepublica]

Having the base template parse some structure data isn't excluded here. I guess allowing for a template opens a can of worms in terms of things potentially being broken downstream.

I think the key thing is to consider which location for the information would get the most action taken from busy developers.

[tim-schilling]

100% The trouble with integrating into the web app is we don't know what's all there. And not everyone logs into their web app portion. I spend a lot of time in the backend without touching the frontend.

I think a multi-faceted approach is solid here.

• Admin
• Messages framework
• Check system

The messages framework and check system probably should use some type of cache to avoid rendering a message more often than once a week. Could be a basic record in the database?

I'm guessing we'd also need a setting that actually enables the messages so that it defaults to off. I wouldn't want these messages to be rendered on production.