Collecting feedback and use cases
I had a vidcall with @dachary of forgefriends yesterday and we talked about the importance of doing User Research, since we are exploring a completely new domain of Social Coding and we must be sure we create something people will actually like to use, of course :)
Another thing we talked about is that we should avoid building new tools if existing ones are available. Instead we might integrate these tools in our processses.
(See also related forgefriends discussion)
This issue is a placeholder for giving shape to that (we are currently still in prep phase).
it's totally possible, but nobody seems to be interested in making an actually good user experience for non-experts
there's still a maddening amount of elitism embedded deeply in the FLOSS community
I suggest that whenever we encounter people stating similar concerns, we collect them here, so we might approach them later on to get their feedback.
In this toot @downee mentions:
👏🏼 Stop 👏🏼 Encouraging 👏🏼 Tech 👏🏼 Monocultures 👏🏼
"....throughout the history of #OpenSource we have a pattern of putting all of our eggs in one or two baskets. But eventually a company needs to make money - so they start boiling the eggs in the basket ... If open source is a garden then we keep planting ourselves in sand and hoping the tide never comes in.
"More generally, I believe that #opensource development should return to its roots as a #freesoftware movement guided by moral principles. Doing so would help the open source community set better boundaries, which would in turn improve software quality, funding, and working conditions. Without a moral center to give developers a spine, they’ll continue to race to the bottom to please corporate interests."
The first example for a SocialCoding Community must be the Community developing the socialcoding Software.
There is a need for evidence that demonstrates the problem that what you call "socialcoding Software" tries to solve. You have an intuition and I think I share it. Nevertheless, this is not enough. User Research must be conducted to collect those evidences.
Do you agree with this or not?
I do agree - to have evidence for something, you need a hypothesis to prove.
- A Community can built better software than an individual.
- A Community can found around a freely shared idea.
- A Community needs Moderation, Mediation and Codes of Conduct.
- A Community can succumb to controversy, fragment and isolate.
Do you agree?
Well yes and it would be valuable to research all those. Let say you collect significant evidence that they are all true. Why would any of them require a specific software? User research is about collecting evidence that a given problem requires a solution implemented with a software.
I'm convinced what you enumerated above is true. But I need hard evidence that creating a software is the right thing to do to have a positive impact on each of them. Because I'm convinced it is not :-)
I think the main hypothesis is:
- Software development is first and foremost a social process.
- Acknowledgement of this and acting accordingly is a key factor for project success.
Besides that any software is merely a tool that supports the automation of some real-world activity.
I think you used a browser and the Gitea UI to write your comment, rather than using Postman CLI and editing raw POST requests to the Gitea API. You use the appropriate tool to make your task easiest.
Any free software project before it is started faces numerous decision points and skill to acquire. This is a first point where support can be offered. We have an existing tool for that, which is the Jekyll website we launched.
We want to continue to give this support all along the development lifecycle, and at all places investigate how social interaction plays a role.
Besides the fact that we have some personal itches to address already, we find our requirements from the user research and people who join the movement and contribute their thoughts.
I see a likely viable platform where we wield the Fediverse - building from the social primitives it offers - to mature a software product along the way and in parallel to our analysis and best-practices we find.
With such a process in place - where we dogfood our own methodology - we will not wildly build some crazy project that no one needs nor desires. And if we take a wrong turn, which may well happen, our project provides lessons-learned for our own methodology.
@dachary I must agree with you that Community Management and Source Code Development Projects are already very well implemented by existing software.
But I believe there is still a need for an accessible network for developers (especially emerging developers) to connect, find ideas and created Communities.
This is the part of Social Coding that needs the most tooling and the most work currently in my opinion.
Regarding the Fediverse as it is currently used, i.e. primarily for Microblogging, I see that all fedizens are continuously talking about the same points. Either complaining or telling about inspiring ideas and resources they found on the web. Very interesting discussions sometimes.
But all is lost into history after a few days. To be mentioned all over again in a future discussion. I don't remember the fedizens that inspired me 2 months ago, and if I want to approach them to start an initiative.. bad luck.
There's no real social network (meaning: graph). I just have timelines and loose sand interaction with following / followers.
I want to like 'bookmark' the interesting stuff and be able to monitor a summary of ideas as they are shaping up over time, with other people offering their 2 cents to it all of the time.
How that can be done in the best way we don't know. But this is the IdeationHub sub-project that we'll investigate as supportive software tool that enriches the fedi we have today.
@CSDUMMI I agree intuitively that there is still a need for an accessible network for developers. I would even go as far as to suggest the Community Management and Source Code Development Projects, although more mature, still have a long way to go before they really support Social Coding.
Since User Research is about observing how people do what they do in a given context, maybe it could start with interviewing developers to figure out how Social Coding activities are carried out at present? And in these interviews there will be facts and first person testimonies that demonstrate actual problems, roadblocks that many people stumble upon.
As I said above, my own intuition is that the solutions to those problems and roadblocks are likely to be a new way to organize developer activities, establishing innovative social norms, relationship to power and authority, different methods and workflows. And very unlikely to require developing a software as a first step. But this should really be discussed only after a User Research report provides evidence of the problem to solve.
Although there are only a few well documented User Research activities (because people tend to conduct them behind closed doors), you are welcome to read about the one that was conducted for forgefriends earlier this year. It is heavily inspired by A Beginner’s Guide to Finding User Needs. I found support occasionally in the OSD community, from people who are experts in the field (including the author of the guide above).
It has been significant work (in the range of a full month worth of work for one person, spread over a period of two month). And the outcome is a set of evidences about an actual problem people experience.
Of course it is possible to discard User Research: the vast majority of projects do. It won't automatically fail a project, but I'm convinced it very significantly reduces the chances of success.
I don't have the time and energy right now to do User Research.
It sounds like a great step for Social Coding to take.
How'd you go about conducting such research? I mean we'd first need people to interview and people to evaluate those interviews. Right?
I think in practice we will do a little of all. We came together on a more modest notion, a simpler project, and the scope is steadily growing. But all we do now is still in a stage of brainstorming, and I think we are content to start small and see where things go along the way. We also have other personal motives to start with this, like in my case working with an AP framework / libs. Where things go and how fast we move also depends on who joins, and I think that is fine.
It's not really user feedback and more the motivations of people and a write up of the conversations on Matrix.
You are right, and I am mindlessly taking over the terminology we talked about to avoid :slaps_head: let's fix it right away..
In this toot by @vertigo the need to address attention beyond pure coding practices is expressed.
Architecture Decision Records
I plan to evoluate myself a minimal format to track Architectural Decisions in Markdown.
Typical IdeationHub use case
Unfortunately, even though I am a Fediverse enthusiast and I cannot stop talking about it with everybody, I am no developer and I cannot practically start working on this, also because my time is too limited to work on such a software. Nevertheless, I hope writing this post could inspire somebody to code something and start a Fediverse platform for movies!
This is typical something that might start a Social Coding ideation flow:
- A great idea is formulated, and fedizens made aware of it.
- Interested folks elaborare further. As more people warm for the idea, a community forms.
- People indicate the type of help they may provide to realize it.
- When there's enough momentum, then a social coding project might be spun off.
- The IdeationHub continues to keep track of the project or projects that relate to the idea.
Supporting old hardware
Was involved in a fedi discussion and the topic of FOSS retaining support for old hardware came up (e.g. Jitsi losing support for Android 6 devices). Especially in poorer countries many old hardware is still actively used. @jayrope mentions:
[..] am on Android 6 myself, so i will be next to be dropped.
I want to broaden the case massively:
I've many friends in poorer countries who can't afford technology updates frcing thm nto OS or even hardware updates. They are basically left with what they got without any option to be taken care of later.
Technology development in Western/rich countries, especially #FOSS, should really keep this in mind and cater to them & us.
We should try to reduce the burden of building software. At this point, software projects require an enormous amount of human effort. Even relatively simple apps require a group of people to sit in front of a computer for eight hours a day, every day, forever. This wasn’t always the case, and there was a time when 50 people working on a software project wasn’t considered a “small team.” As long as software requires such concerted energy and so much highly specialized human focus, I think it will have the tendency to serve the interests of the people sitting in that room every day rather than what we may consider our broader goals. I think changing our relationship to technology will probably require making software easier to create, but in my lifetime I’ve seen the opposite come to pass. Unfortunately, I think distributed systems have a tendency to exacerbate this trend by making things more complicated and more difficult, not less complicated and less difficult.
@how was involved in feedback on a great article by spacecookie:
Organisations, groups, and projects under capitalism have the tendency to centralise. This is both because of monetary incentives (it might be cheaper to just have one of something than many), as well as authority incentives; it is easier to control an organisation that is structured hierarchically.
The way that we organise free software projects is impacted by this societal framework, which replicates a lot of the issues that organisations, projects, and companies under capitalism face as well. Maybe unsurprisingly our solutions to these issues are also largely similar: personality based, and hierarchical in nature.
Projects often also use the same metrics as capitalist society for success: growth, reach, and audience appeal. This replicates the phenomenon of representative democratic systems and proprietary technology creators of pandering to the majority and letting needs by minorities largely go unanswered.
In this essay we propose an organisational structure for software and technical projects that removes the notion of “upstream”, and introduces a collective ownership approach of software and technical knowledge. Freedom of ideas (the fundamental basis of free software) is a core requirement for this approach.
Furthermore we aim to put this theory into practise by creating a software syndicate around the DREAM project, a collection of p2p collaboration tools developed by a variety of people (see “Appendix A” for more).
This essay can not hope to solve all problems related to this idea, but to start a discussion about the merits and advantages of organising in small-scale, decentralised communities. Our hope is that this sparks conversation, interest, and motivation in others to form software syndicates of their own, to communally own, develop, and maintain the technologies that our lives are built upon.
Must definitely review and find out about related material that also exists.
Splendid video by @email@example.com about common challenges and solutions regarding the positioning of FOSS to consumers of the software. The video also highlights a different kind of involvement of these people that aligns really well with Social Coding. Found via this toot by @IMakeFOSS
(Couldn't find this video on yewtu.be or other invidiuous instances)
Nick Sellen on Social Coding matrix provided a great link:
Reminded me of this article https://www.shareable.net/6-design-dilemmas-to-address-when-setting-up-digital-platforms-for-resource-communities/ and this point:
Quantified vs Qualified Values:
Which (trans)actions, relations, aspects of identities and reputations should be captured and formalized? And which are best left outside of the formal system, for community members to address informally in their social interactions?
SustainOSS has created a Report on OSS in 2021 that contains a lot of interesting input for Social Coding. Here's the PDF link:
(Also included as attachment)
Deleting a branch is permanent. It CANNOT be undone. Continue?