Learn more about these different git repos.
Other Git URLs
We have groups in FAS, and from my experience it feels like a lot of newcomers feel that they must be part of a group to participate in work. We know this isn't true. Most groups don't provide any special access (the only one I know that really does is the package maintainers group, and maybe the QA group gives more rights on bugzilla?).
There are also pagure/github/gitlab groups which people may confuse with FAS groups.
Do we need to have a page somewhere in our docs explaining groups and noting that in most cases, the groups are not required to get started, so people should not focus on on them too much?
I expressed my thoughts some time ago. To summarize, while if you are a packager it is pretty clear to you and to the world that you are a contributor, in other places there is not a way to say "hey, I'm in the marketing team", "I'm a doc writer" or "I'm a translator". Maybe people thinks that being part of a FAS group, distinguish them from the generic user. It is true that in the majority of the cases you don't need to be part of a FAS group in order to contribute, but maybe the badge system is the way to develop some more commitment, reconnaissance to contributions.
I see one problem in general to begin with---the distinction between "user" and "contributor". We've had this multiple times on Ask Fedora etc., and we keep needing to explain to people that we don't have this strict line like corporate software companies do. We're more on the lines of "everyone is a community member". This is new to newcomers, who are used to the market way of doing things---companies develop and sell, users pay and use, and there's no cross over.
We could write something up about this also I guess.
The second one I see is about "recognition", and it's a much larger question that is relevant to all of FOSS pretty much. Yes, I understand that people do want to be recognised for their work, especially those looking to build their profiles to get better jobs. The question is what sort of recognition can we provide, and what is appropriate.
Direct recognition in terms of monetary payment is out of the question in volunteer communities, however the community does sponsor community members at conferences and so on, so there is some of this indirectly.
Badges are perhaps the easiest, but I am not sure of how well the badges project is being maintained (I think I heard of more folks joining in, and the different bodies focusing on ensuring that the badges infra etc. is maintained, but I don't know detals. @hhlp would you know anything with your Mindshare hat on?)
FAS groups are not the best way in my book. For one, they are not displayed anywhere apart from in FAS. Next, being part of an FAS group does not mean you're active there or part of the team. I'm an example of this---I've accrued multiple FAS group memberships over the years, but now that I'm limited by time, I'm not active in many of these.
Here's a question that I'd like to discuss from the FAS groups bit. Why does being a packager make it clear to us and the world that we are contributors, but being active in another team does not? Is this how people see the community Is it related to how we promote/project the Fedora community (for example, do our websites etc. give too much focus on packagers and not on other teams?)
I think the final, most "organic" recognition is from our peers. It's when we work with each other and thank each other. There is no measurable/tangible recognition here, so I see how this may be formal enough in a lot of cases I guess?
My suggestion is to create a work-flow for a new joiner, with a starting point. Make the Doc thing a separate work-flow. Just like how we fill a jobs portal. that would give the group owners a clear picture about the new joiner and can initiate the needed roles accordingly. Though this is not a corporate, this structured approach makes it easy for the joiner to track himself.
We already do have a workflow in place @naraiank : have you gone through the information in your welcome-to-Fedora ticket?
We do not "apply" for positions etc. in the community, and no one assigns tasks to others---this is not what "group owners" do. People work on what they find interesting, and what they want to put their resources into. Basically, we take initiative to help where we can/want.
So, please go through your welcome to Fedora ticket first, learn about what/where/why/how/when the community does things, and then familiarise yourself with the sub-group you are interested in by introducing yourself there and learning about their activities.
@ankursinha IMHO, we can separate the types of $USER in two diferents ways:
making it clear:
The $USER has FAS account, and you can do all this things:
https://ask.fedoraproject.org/t/what-can-i-do-with-my-fedora-account-fas/1475/
Is $USER desicion What they would like to do? and How the would like to enfoque their Journey inside the community?.
Regards.,
As a recent newcomer, I missed something that helped me feel part of a group or as a "real contributor". When I started contributing to the kernel, about a year ago, it felt more concrete to me in that: I sent a patch, someone reviewed and my patch was merged. So, I kind of knew what I was helping: I was writing code for the kernel, even if it is a simple typo patch, and moreover I really feel like helping.
As a recent newcomer to the Fedora community, I feel disconnected from things. I'm currently joining the Workstation WG, but I feel more like a guest than a member of the community.
So, in this sense, I believe that creating documentation explaining groups (maybe even listing some contacts, work hours, and possible tasks) and noting that groups are not required to get started would be pretty nice to have.
PS I know that the documentation about the SIGs exists. But they have spread all around and it's hard to find how to start in a SIG when the information is spread. That's why I suggested a little summary from each group and task ideas.
About the recognition question, I believe that everybody volunteers for a reward. Maybe the reward is not financial, and maybe it's not for resume purposes: maybe the person wants to feel that it's helping a beloved project to grow. And, as beginners, we like to have some positive reinforcement. As an example, in the kernel, having a patch approved is a kind of positive reinforcement. In the counterpart, being a part of a discussion on an issue doesn't bring a lot of that "I helped!" feeling.
Anyway, I believe the docs might help beginners to understand their role in the community and how they can begin.
PS "How they can begin" can be in a more concrete way, like in GSoC or Outreach, where there are tasks ideas. "Join the mailing list", or "Join IRC" sometimes do not help that much as sometimes the beginner doesn't even understand what is being discussed.
Thanks @mairacanal , that's very useful
The one difference between a community like Fedora and general code projects is that one knows what to expect with the code project. There's one, quite standard, way of contribution---bugs/pull requests.
It doesn't work like that in Fedora, unfortunately. For example, the workstation WG doesn't develop Fedora in the same way as upstream code communities develop their software. The workstation WG relies on lots of package maintainers to maintain packages in Fedora (including themselves), and the workstation WG mostly makes policy decisions about what goes into the workstation image.
Traditionally, we've had task based workflows. That's how things like easyfix came along. However, this only works for people who have some experience of FOSS contribution, like you. Others that haven't had an experience of pull requests/git/ find the task based workflow quite hard and in a lot of cases they feel left out for not being as technically skilled.
So, we changed to a people based workflow---get to know the community first, the people, and one will find plenty to do and participate in---both technical and non-technical tasks.
Thanks @hhlp. I think we can assume that most people expect some positive reinforcement as @mairacanal noted. It doesn't have to be tangible, but even feeling part of the team counts.
Are you aware of the state of the badges project? Do we know if any resources are being dedicated to it to keep it maintained etc.?
PS: I think we're going a bit out of scope here.
The question remains---are groups in FAS and their function confusing to newcomers? Confusing enough that we need to document them and their function?
PS: I think we're going a bit out of scope here. The question remains---are groups in FAS and their function confusing to newcomers? Confusing enough that we need to document them and their function?
@ankursinha
Regards
Maybe there is an asymmetry in what the community and the beginners think about the concept of "contributing": the beginner thinks it must be a part of a group in FAS (or Join a SIG), the idea of having his name on a "members list" and the community thinks otherwise.
So, it might be worth a section (maybe in How to be a successful contributor).
PS: I think we're going a bit out of scope here. The question remains---are groups in FAS and their function confusing to newcomers? Confusing enough that we need to document them and their function? Maybe there is an asymmetry in what the community and the beginners think about the concept of "contributing": the beginner thinks it must be a part of a group in FAS (or Join a SIG), the idea of having his name on a "members list" and the community thinks otherwise. So, it might be worth a section (maybe in How to be a successful contributor).
@mairacanal
That is well documented here:
https://docs.fedoraproject.org/en-US/fedora-join/contribute/successful-contributor/
PS: I think we're going a bit out of scope here. The question remains---are groups in FAS and their function confusing to newcomers? Confusing enough that we need to document them and their function? Maybe there is an asymmetry in what the community and the beginners think about the concept of "contributing": the beginner thinks it must be a part of a group in FAS (or Join a SIG), the idea of having his name on a "members list" and the community thinks otherwise. So, it might be worth a section (maybe in How to be a successful contributor). @mairacanal That is well documented here: https://docs.fedoraproject.org/en-US/fedora-join/contribute/successful-contributor/ Regards.,
Maybe I wasn't pretty clear. I mean, add a section to the "How to be a successful contributor" documentation about groups and how they work. Specilly as this documentation refers a lot to the idea of "team", so the beginner can think that we suppose to join a team through a FAS group.
+1, I'll add a section to the page. I'm working on improving the "how to be a successful contributor" page already in this branch, so I'll add this to the list of things that need to be done:
https://pagure.io/fedora-join/fedora-join-docs/tree/update-successful-contributor
Metadata Update from @ankursinha: - Issue assigned to ankursinha
Direct recognition for documentation and help comes in two ways - Git forge public profile/contribution graph on the personal profile header, and solutions provided on Ask Fedora. These are your personal portfolio that is shared publicly. Docs contribution can be measured the same way as coding. This is true for anyone who aspires to work as technical writer and helper.
Another factor to measure contributions to the team is the number of new comers who you onboarded and stayed on, and as well as the number of contributions from casual volunteers (who don't hang around in Meeting/Discussion). The latter for me does not really matter for overall health of the community. We need "gigs" contributions from external members and subject matter specialists. I had them in Docs team in 2022 to introduce docs linter (vale).
Soft factor to be considered 'recognition' is precise and prompt feedback on issue and PR/MR, which is a thoughtful way to say appreciation. It is hard to count, but works well to build teamwork and sense of belonging and achievement.
Log in to comment on this ticket.