#231 What to say to newcomers
Closed: Fixed 3 years ago by ankursinha. Opened 3 years ago by alciregi.

Hello.
I'm a little trapped.

As you may know, many (the most) of the newcomers (at least the ones contacting the Join SIG) would like to contribute in development tasks. Many of them introduce themselves as developers (Python, C, or any other language), or web developers (frontend, html, css, frameworks, etc.)

Honestly, I personally don't know where to point them. (Maybe because I'm not strictly involved in software development).

Many of the time they are also fledgling in a community work, that is perfectly fine.
They are excited, it's also fine. They would like a task assigned to them. But, apart the fact that we are not here to assign any task [1], the point is that it seems they don't realize that it is not so simple to write code for a whatever already spinning software. I mean, every project has processes, workflows, planning, discussions, etc. It is not simply writing lines of codes.
And, as said many times, the main work of our community is not writing software. We reply many times that we are downstream to the software included in the distribution. And also if many of the community members are involved in development of such software, it is not so simple. Mmh.

At the same time it seems to me a bit demotivating replying: "hey, you have to go to github or to gitlab and find a task". It sounds like "you are on your own". That is true :-) but it is rude.

I would like to say to those people that Fedora is not only software, it is not only coding. There are many other areas needing help, like marketing (bloggers? videomakers?), designers, writers, translations, helpdesk, everything. Well, a way to contribute is also by starting from simple tasks, also by simply finding bugs/errors here and there (a little typo in the docs or on web sites), in that way you could start to know other people, to know workflows, to know if an area is still alive or it is better to focus on something else. But sadly, those people would like to write lines of code without inspecting other facets of our large community (maybe this is only my impression).

We have https://fedoraproject.org/easyfix, but it would need some love.
Do we have a list of Fedora specific (or striclty related to Fedora) projects hosted on pagure/github/gitlab/whatever?
Maybe the point is that there is a lack of mentors, but what we can do? Maybe people involved in development should offer their help in the Join SIG?

Do you have thoughts to share?

[1] IMHO, it is up to people to find the tasks they are interested in, we are here to melt their doubts, to facilitate their experience

cc: @riecatnor @jflory7


Heya,

Yes, this is a very very common issue. From my experience, most of them want to get into "coding" because they're not really aware of what else is out there, and how collaborative development and the full software development pipelines work. (Showing some "coding" experience is also the most traditional way of improving their CVs to make themselves more employable in lots of job markets.)

The Welcome-to-Fedora workflow is explicitly designed NOT to be task oriented. It is people oriented. We want people to be part of the Fedora community before they start working on tasks. So, I never suggest tasks, not even easyfix. I even avoid pointing them to a team, unless they seem to be experienced enough with FOSS etc. to be able to jump right in. (If we point them to a team right at the beginning, they miss out on everything else that Fedora has to offer---where they may find other interests!) So, for a majority of folks, I will open a ticket, and ask them to first explore Fedora. Encourage them to hang out in channels, attend meetings, and keep an eye on mailing lists so that they get an idea of how things work. Only when they are better aware of how Fedora works under the hood can they make an informed decision on what it is they want to do.

Perhaps we can add something like "You should spend maybe half a release cycle (3 months) just hanging out in channels and on mailing lists to get an idea of how things work" to the Welcome-to-Fedora ticket template?

So, in short: actively steer people away from tasks to begin with. Steer them towards people. When they know how the people of Fedora work and what we do, it's very likely that they'll easily find tasks to work on.

Hi @alciregi, here are my two cents

As you may know, many (the most) of the newcomers (at least the ones contacting the Join SIG) would like to contribute in development tasks. Many of them introduce themselves as developers (Python, C, or any other language), or web developers (frontend, html, css, frameworks, etc.)

The newcomers stating their proficiency in said programming language or technology actually infers the fact that they hold Fedora as a community in high regard and want to be just as useful as they believe the community is, which in fact is a good thing.

Honestly, I personally don't know where to point them. (Maybe because I'm not strictly involved in software development).

Many of the time they are also fledgling in a community work, that is perfectly fine.
They are excited, it's also fine. They would like a task assigned to them. But, apart the fact that we are not here to assign any task [1], the point is that it seems they don't realize that it is not so simple to write code for a whatever already spinning software. I mean, every project has processes, workflows, planning, discussions, etc. It is not simply writing lines of codes.

That's the point. Helping folks at Join SIG don't necessarily need to point the newcomers to tasks. The "Welcome to Fedora" pipeline of introducing folks to the community and exploring it organically is well-laid and that would actually help retain members for a long time. Just imagine how boring things become when you are just told what to do, irrespective of the fact about what you are good at as opposed to the excitement felt when you get to explore stuff and decide what to and what not to choose. The entire process of probing into things can be intimidating at first (ask @ankursinha how many times I expressed disdain over the use of mailing lists and @siddharthvipul1 how many times I was impatient enough to ignore the very existence of timezones) but the entire process allows you to get a perspective of things and let the newcomer realize that they are welcome to help but more than that, they are welcome to just be here.

And, as said many times, the main work of our community is not writing software. We reply many times that we are downstream to the software included in the distribution. And also if many of the community members are involved in development of such software, it is not so simple. Mmh.

For every newcomer, stating this becomes a chore I know. After all how are we to blame or be held responsible for explanation when they themselves have held Fedora to be something that it isn't. We are not some spectacled folks who spend over 12 hours a day writing quality software in the basements of our house, as they might for think us to be. The community appreciates (read, needs) programmers, documentation folks, designers, quality analysts, devops personnels, community managers and much more. Expecting them to understand this from the get-go can be to much to ask for and might just end up driving them again. If it comes organically to them, it would be pleasant.

At the same time it seems to me a bit demotivating replying: "hey, you have to go to github or to gitlab and find a task". It sounds like "you are on your own". That is true :-) but it is rude.

:100:% agreed. But I cannot think of an easier or friendlier way of stating the same. We need to make them realize that if they are on their own, that's because we want their time at Fedora here to be pleasant. (How do we do that though?)

I would like to say to those people that Fedora is not only software, it is not only coding. There are many other areas needing help, like marketing (bloggers? videomakers?), designers, writers, translations, helpdesk, everything. Well, a way to contribute is also by starting from simple tasks, also by simply finding bugs/errors here and there (a little typo in the docs or on web sites), in that way you could start to know other people, to know workflows, to know if an area is still alive or it is better to focus on something else. But sadly, those people would like to write lines of code without inspecting other facets of our large community (maybe this is only my impression).

We might want to include the easyfix site at the welcome ticket for the newcomers maybe. If they really want to code, we can let them start with some easy-to-do fixes so that they would begin to feel engrossed from the very beginning with the feeling like they are actually doing some stuff. But I can understand your impression too from the little stay I had here. Most of them are students and if I say about those originating from my place, they are inclined to get the hard work done without even having any field study because maybe you are appreciated when you play the hero. Even a very close friend of mine whom I suggested the community to be a fun place to hangout and work for, gave up just after a week. Could you imagine :laughing:?

We have https://fedoraproject.org/easyfix, but it would need some love.
Do we have a list of Fedora specific (or striclty related to Fedora) projects hosted on pagure/github/gitlab/whatever?
Maybe the point is that there is a lack of mentors, but what we can do? Maybe people involved in development should offer their help in the Join SIG?

I proposed a rewrite of the Easyfix site to make it look and act like something that would be appealing for the newcomers. Also, I have explored the codebase and have found it to be in familiar grounds to what I know but maybe (like you said), we would need mentors. Lots of em.

Hi @ankursinha,

Yes, this is a very very common issue. From my experience, most of them want to get into "coding" because they're not really aware of what else is out there, and how collaborative development and the full software development pipelines work. (Showing some "coding" experience is also the most traditional way of improving their CVs to make themselves more employable in lots of job markets.)

Totally agreed with the first part where it is more common among the younger developers to feel that way due to inexperience of the collaborative development or a basic idea about how the software development paradigm works while for those who are experienced in the industry, find it easy to blend right in and find it okay to explore the community first. I am not really sure about the latter part though as that would mean that folks are joining the community because they have an incentive and not because it is fun. I explored some of them and their participation unfortunately died down under a week or two which basically means that they know that they are "good at doing stuff" but they are bothered by the notion of exploring to "find that stuff". There's not much we can do about them and thankfully there ain't many of them.

The Welcome-to-Fedora workflow is explicitly designed NOT to be task oriented. It is people oriented. We want people to be part of the Fedora community before they start working on tasks. So, I never suggest tasks, not even easyfix. I even avoid pointing them to a team, unless they seem to be experienced enough with FOSS etc. to be able to jump right in. (If we point them to a team right at the beginning, they miss out on everything else that Fedora has to offer---where they may find other interests!) So, for a majority of folks, I will open a ticket, and ask them to first explore Fedora. Encourage them to hang out in channels, attend meetings, and keep an eye on mailing lists so that they get an idea of how things work. Only when they are better aware of how Fedora works under the hood can they make an informed decision on what it is they want to do.

Perhaps we can add something like "You should spend maybe half a release cycle (3 months) just hanging out in channels and on mailing lists to get an idea of how things work" to the Welcome-to-Fedora ticket template?

:thumbsup: for a suggested wait. :thumbsdown: for a compulsion wait. Like I said, if there are folks who stick around and are able to find what they are looking for under the given time - they are more than welcome.

So, in short: actively steer people away from tasks to begin with. Steer them towards people. When they know how the people of Fedora work and what we do, it's very likely that they'll easily find tasks to work on.

I think, tasks are what keeps folks in bound. The completion of those tasks, no matter how small they are, give them the sense of responsibility and belongingness. The way exploring can be intimidating to people can compel them to give up. I think we should "suggest" tasks if they are up for them once they have explored the points in the welcome ticket but being just a "suggestion", it is okay if they don't do them.

I did not say there should be a compulsory wait. It says "should", not "must". It can be worded better if that's unclear.

It was because the task/easyfix workflow was not keeping people around that we moved to the people based workflow. With tasks people focus on the technical aspects that are needed to complete tasks---and when the tasks are complete unless more tasks with the same requirements turn up, people do not find a reason to stick around. It does not give the person any incentive to get involved in the general workings of the community---all they want to do is do the task, and move to the next. That is not how a volunteer community works---it is never task oriented. In fact, most of the time tasks only come up because the people of the community sit together and think of what they would like to do next. So we need people to get involved in the community, not just to do tasks.

With the focus on getting to know the people of the community, people stick around irrespective of whether they have tasks---in fact, they are keen to help with tasks that may require them to learn new skills to help their friends in the community. They stick around with us, their friends, and we share tasks together---no one assigns tasks to anyone because there is no hierarchy. It teaches all involved how a volunteer based community, where we are all equals, works. The relationships are most important.

The new people oriented process took a lot of time for us to develop, so i would really ask people to not go back to the task oriented process. It does not work. We do not want a contractor type community base where people come in, do tasks, lose interest when there's nothing to do in their specific area of interest and leave. We want a community where people hang around simply because they enjoy talking to each other. The tasks will come---look at how varied the tasks we all do are. It's because we are friends that we get involved in each others projects, not because we're looking for tasks to do. Most of us are so busy that we'd be better off without more tasks. We do it because we are friends and we want to support our friends in the projects that they are putting their time into.

Please everyone read this so we're all on the same page:
https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-focused-workflow-for-newcomers/

TLDR: there's almost nothing we can do for people that are looking to "practice skills". We can't keep them around. Once they've learned what they set out too, there's nothing keeping them here. All we can do is give people a reason to stay irrespective of the work---so irrespective of what products we're coming up with, or what the community is focusing on, they'll stick around because they're Fedora community members.

The best way of getting people involved in tasks, if that is required, is to engage them in conversation about their interests and see what they would like to do, or how they think they can improve something. Let them open the task, let them speak to the team and see what the current status of the project is, and in this way, let them learn what would be useful to do.

So whichever way I look at it, it comes down to making newcomers more familiar with the people. Make them comfortable enough to be able to jump in on a mailing list and ask questions or start a discussion. The tasks will come as they speak to more folks and learn more about how things work. There's never a shortage of tasks XD

I did not say there should be a compulsory wait. It says "should", not "must". It can be worded better if that's unclear.

Aww my bad, Ankur. That's why I stated the two nuances. (The +1 one and the -1 one)

It was because the task/easyfix workflow was not keeping people around that we moved to the people based workflow. With tasks people focus on the technical aspects that are needed to complete tasks---and when the tasks are complete unless more tasks with the same requirements turn up, people do not find a reason to stick around. It does not give the person any incentive to get involved in the general workings of the community---all they want to do is do the task, and move to the next. That is not how a volunteer community works---it is never task oriented. In fact, most of the time tasks only come up because the people of the community sit together and think of what they would like to do next. So we need people to get involved in the community, not just to do tasks.

Agreed. If it would be like that they folks would be jumping from one task to another without actually seeing what;s beyond those tasks. But maybe, we should give them both and ask them to choose from. Not everyone likes to stick to tasks continually, and who knows - they may find their time pleasing on Ask Fedora or finding bugs here and there.

With the focus on getting to know the people of the community, people stick around irrespective of whether they have tasks---in fact, they are keen to help with tasks that may require them to learn new skills to help their friends in the community. They stick around with us, their friends, and we share tasks together---no one assigns tasks to anyone because there is no hierarchy. It teaches all involved how a volunteer based community, where we are all equals, works. The relationships are most important.

We need to make the same thing understood to the newcomers as well. As much as we don't have a choice on their perspective when they see Fedora as a big developers guild or something - we need to make them realize that it is okay to not write code and still be just as valuable to the community as the second person is. The existing members understand the same but I believe that the same is not conveyed to the newcomers properly and when they don't get what they come to expect (something that unfortunately they are at fault for), they leave :cry:.

The new people oriented process took a lot of time for us to develop, so i would really ask people to not go back to the task oriented process. It does not work. We do not want a contractor type community base where people come in, do tasks, lose interest when there's nothing to do in their specific area of interest and leave. We want a community where people hang around simply because they enjoy talking to each other. The tasks will come---look at how varied the tasks we all do are. It's because we are friends that we get involved in each others projects, not because we're looking for tasks to do. Most of us are so busy that we'd be better off without more tasks. We do it because we are friends and we want to support our friends in the projects that they are putting their time into.

I'd say let's give them a choice.

If they want to explore at the start - good.

If they want to do tasks at the start - good as well.

Please everyone read this so we're all on the same page:
https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-focused-workflow-for-newcomers/

I read it some 8 months back and it is still as good as it was then. :smile:

Please everyone read this so we're all on the same page:
https://communityblog.fedoraproject.org/fedora-join-is-trying-a-new-people-focused-workflow-for-newcomers/

Yes. This is clear, at least to me. Indeed my first suggestion to people in the Join channels, is to look around, know and talk to people, subscribe mailing lists and read news and docs.

My concern is like:

  • Jen comes to Fedora and wants to contribute. She’s new to Fedora, but she already know what she would like to do.
  • She get in touch with the Join SIG. And we stop her enthusiasm: "hey, calm down, we have no tasks for you"

:smile: This is obviously an oversimplification. We never act like that. I think that it is not our intent to stop enthusiasm, it is the contrary.

But while if someone is interested in packaging, or in documentation, or in writing articles, or in art/design, we (me) are able to suggest: "hey, cool, we have a magazine, we have a design/marketing team; hey subscribe to the devel mailing list and read these packaging guidelines", I personally lack of suggestion for people that would like to write code (that is the majority of people that get in touch with Join SIG), and even for people wanting to contribute to the web sites (does the website team is in a good shape? 🤔)

Yes, the workflow really is for absolute newcomers who do not know how things work. For advanced beginners, it's trickier: we can't suggest specific tasks, we can only point them to where they are likely to find tasks. So it'll be similar suggestions but they don't start from step 0, they start from step 5 perhaps: "this is the mailing list/team where this kind of work happens---hang out there, see what's going on. Here's the easyfix list: see if anything there seems interesting" etc. The assumption here is that these advanced beginners will be experienced enough to be able to jump in to a new team/ML/environment and figure out what they want to do.

Coding is a really hard one. We really do not do a lot of coding---we are downstream. Even for infra etc., we're slowly moving towards paying for hosted tools so that we don't have to spend time on developing them ourselves. The really core stuff, like the new FAS (AAA) is being built in-house by the CPE team, and that's not the kind of task a newbie can jump into. The websites also don't need a lot of work---from what I see they are updated every release, but there doesn't seem to be any active development happening there.

So, if someone really only wants to do coding, and isn't happy with something related like maintaining packages (which also requires understanding the code etc.), we can't do much but bounce them to upstream projects and let them make their own way. :/

Random idea for newbies looking to code:

  • them: Hey, I'd like to code
  • us: great, we're downstream but you can always help fix bugs in software! What software do you often use on your Fedora system?
  • them: I use A, B, C
  • us: awesome: here's bugzilla, with millions of bugs. Why don't you look at the bug lists and see if you'd like to fix some? You can submit patches and contribute to the software!

How does this sound?

us: awesome: here's bugzilla, with millions of bugs. Why don't you look at the bug lists and see if you'd like to fix some? You can submit patches and contribute to the software!

We can do that. Or we can show them the Easyfix site (which would contain at least some tasks to help them get started with while feeling involved and not intimidated)

Before even showing that, we'd want to let them explore Fedora as a community as folks do now. When they are done with that and feel like they do not have anything else to see, we provide them this and allow them to proceed on their own accord because coding is what they wanted to do in the first place.

Yeh, the one issue with EasyFix is that I don't see a lot of package maintainers marking bugs as EasyFix regularly. And when they do, these are related to the package rather than the software.

If you look at easyfix now, there are only 8 tickets from bugzilla:
https://fedoraproject.org/easyfix/

The pagure etc easyfix issues are not necessarily upstream traditional based. Most of them are generally community based.

So, for these people, we still open the ticket but we can add additional information about how to search bugzilla to find bugs for packages they used. How does that sound?

@ankursinha Now that's something we can do that is going to help the "coders". The information is right there but it does need looking into which can be scary for some newcomers. One thing we can do is get most (if not all) devs and maintainers to use easyfix to file well-documented issues.

I have asked people on the devel list to use the EasyFix etc tags on bugzilla, but it hasn't caught on. So unfortunately, we may not be able to depend on them doing it regularly :(

I have asked people on the devel list to use the EasyFix etc tags on bugzilla, but it hasn't caught on. So unfortunately, we may not be able to depend on them doing it regularly :(

Arrey true :frowning:

Will it be safe to assume that the "coders" can read and understand the code done by the fellow devs of the community once they are directed towards the issues? There's only so much that can be done beyond this.

Depends a how the code is written, does it relay the intent ? It takes a while to look around and get some grip on how things work.

Yeh, well if they want to code and contribute to software, they need to be able to read the source code and understand it, along with the build system and all that. That's beyond what we can help with.

We can point them to all the bugs/issues they can investigate in the software Fedora ships. Hopefully, that'll also teach them to contribute to upstream and the relationship between upstream and downstream distributions.

It isn't ideal, because not all bugs on Fedora bugzilla may still be open upstream, but from a Fedora perspective, this is the best we can do.

I.e., we cannot teach people the code for a particular software. No tutorials, no documentation can do that. That journey is something everyone has to make for themselves :)

@alciregi @ankursinha True. But at least, let's give them the choice to pick a direction that they want along with the discretion/advice.

@alciregi @ankursinha True. But at least, let's give them the choice to pick a direction that they want along with the discretion/advice.

Sorry, what are we talking about here? (Advice about doing what?)

The discretion that I'm mentioning here would be about the sheer absence of
guided support when they immediately jump into development and that,
exploring the community first hand would be a much preferable option to
start with.

(Sincere apologies for writing this via mail - Having dinner here :P)

On Wed, 2 Dec, 2020, 10:44 PM Ankur Sinha, pagure@pagure.io wrote:

ankursinha added a new comment to an issue you are following:
``

@alciregi @ankursinha True. But at least, let's give them the choice to
pick a direction that they want along with the discretion/advice.

Sorry, what are we talking about here? (Advice about doing what?)
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-join/Fedora-Join/issue/231

Yes, as I said in my comment before: we still open the ticket, but we include information about bugzilla there to help them find traditional coding related tasks, and perhaps even help them find the upstream for the software they use and wish to work on. We continue to support them in the usual way---answering questions, pointing them to resources where possible. We cannot support them with the actual debugging and we can't always support them with queries about upstream projects. (We'll all have to learn the code base + development pipelines of all the software in Fedora first to be able to help with that.)

@alciregi : to summarise the long ticket:

  • we continue to open tickets for them
  • we ask them additional questions to help them find software they can code for. For example: "what software do you use, and would perhaps like to code for?"
  • we help them find bugzilla for that package, and its upstream. (assuming they're using Fedora)
  • we continue to answer general questions and point them to necessary resources (where possible).

So in a way, we funnel folks through the same process but give additional info to people who explicitly want to code to help them find upstream etc.

@alciregi : to summarise the long ticket:

  • we continue to open tickets for them

Obviously.

  • we ask them additional questions to help them find software they can code for. For example: "what software do you use, and would perhaps like to code for?"

This is a good question.

  • we help them find bugzilla for that package, and its upstream. (assuming they're using Fedora)

I didn't think to that way.

  • we continue to answer general questions and point them to necessary resources (where possible).

Obviously

So in a way, we funnel folks through the same process but give additional info to people who explicitly want to code to help them find upstream etc.

Great. I have more ideas now. Thanks.

@t0xic0der thanks for sharing your enthusiasm. I fear that the issue with easyfix site is that we risk to lead people in a place somewhat outdated, not well maintained, where easyfix isn't easy at all if you are outside the workflows and pipelines. :-/

Just a thought: maybe another ticket is needed, what do you think about a survey for newcomers? Like: what do you think about the community, age range, student/worker/retired, what do you expect, why you are here? Or this could be a bit scary/invasive? 🤔

I didn't think to that way.

Doing like that would only push them away :laughing:. We can direct them to places where they can have an easy start with an advice that they are highly recommended to first explore Fedora as a community. It is just as important to understand the workflow and comply with the other members working on the same code - just as important as it is to code.

@t0xic0der thanks for sharing your enthusiasm. I fear that the issue with easyfix site is that we risk to lead people in a place somewhat outdated, not well maintained, where easyfix isn't easy at all if you are outside the workflows and pipelines. :-/

The underutilization or misutilization of the site can be an issue. The way I see it, easyfix should encompass issues that are self-contained and well-documented enough to get newcomers onto the code with as minimal effort as possible. Remember, "coding" newcomers would have to put a significantly higher effort to understand the code and the workflows which are already in place but there's only so much that we can do about it.

Just a thought: maybe another ticket is needed, what do you think about a survey for newcomers? Like: what do you think about the community, age range, student/worker/retired, what do you expect, why you are here? Or this could be a bit scary/invasive? 🤔

:thumbsup: to that.

We would also need a ticket to make sure that the Easyfix site keeps up with the requirements even today.

Let's close this ticket. We're all saying the same thing now, but going around in circles :D

@alciregi : I'm not so sure about the survey, but let's open a new ticket and discuss that?

@t0xic0der : There are already tickets to improve easyfix. Please feel free to take them up---easyfix is a larger project that needs someone to drive it IMO.

https://pagure.io/fedora-join/Fedora-Join/issues?status=Open&search_pattern=easyfix&close_status=

(We need to remember that easyfix isn't just about making a good easyfix list. That's really the easy part. The harder part is getting community members to do the work to mark good tickets as easyfix. )

Metadata Update from @ankursinha:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata