I think this is certainly kind of possible. The current Center for Humane Technology started as Time Well Spent movement, focused more on our own healthy habits around the use of digital technologies, and how software could be designed for that. This was also at a time where there was a lot of focus on tools to help avoid repetitive strain injuries (RSI), by collecting various metrics about computer use.
The thing with info overload is how personal it is. One person thrives in a flood of information, while another needs deep focus on singular tasks. Different kinds of activities have different needs for such focus. So any software support should facilitate a large extent of personal tweaking. Create something akin to an “Attention profile”.
As a community facilitator and weaver in public (and now “weaving in commons”), I willingly accepted a big info overload flooding in from countless different channels. Dealing with that to an extent is essential part of the tasks of any community facilitator / commons janitor. Even knowing that it comes with detrimental effects, like losing an ability to focus (unless carefully planning time for this).
Coding is social. Different stakeholder roles in the software development process require different levels of information density and attention. This recognition exists insufficiently, esp. in FOSS movement, and where big gains can be made by better supporting these individual roles.
Given the breadth and scope of the FSDL, there is no prescriptive way to move in the good direction, but everything depends on preference and circumstances. Every initiative favors their own tailored approach. That is the level where SX should accommodate, and then the strategy you propose becomes more of a tactical pattern in a crowdsourced library of good practices.
Social coding commons by means of hedonic peer production offers a solution for facilitating the crowdsourcing process. By ensuring that contribution is intricate part of people’s own improvement process, thus providing the necessary intrinsic motivation to contribute. These contributions over time aggregate more and more value to the FSDL and SX methodology, creating a feedback loop.
Since probably numerous best-practices exist, Social experience design has the concept of SX Instrument sets, which are categories of best practices to be filled with SX Instruments, the good practices themselves, packaged for direct application and use.
Today, in a different context, I wrote the following in the Social experience design chatroom, that relates to this:
What a Social coding commons and any movement for change should do, is facilitate incremental improvements and value being added all the time to evolving solutions across the full holistic scope. And be able to breakdown the many intricate solution aspects and delegate to the appropriate motivated interest groups who can deal with them.
One of the things that SX brings along is the notion of “growing software” through a timeless evolutionary process (bottom-up), where a solution gradually matures, boosted by spikes of (top-down) active software development that occur during its lifecycle.