+1
We had a similar discussion in Akademy! Since string tags can't be added, we have to create either a group or a project.
Then, we may use the phabricator API to serve the junior jobs wherever needed. And, why not, create sth similar to the findyourway of plasmobile for KDE junior jobs in general.

Maybe we could add a "Junior Job" tag to phabricator? At the moment junior jobs are spread all over phabricator and hard to find. With a global "Junior Job" tag we could collect all these jobs in one place and new contributors could search threw them to find something that fits them.

@sitter - I just wanted to loop you in here since you had offered to script the NEEDSINFO closure bot.

AFAIK two people in two beds in a room is the default that KDE eV sponsored solution since basically halves the price for hotels in rooms, sharing more then 2 people in a room gets annoying and usually is avoided and only one person per room is too expensive and only granted in some cases, but please confirm with the board what i'm saying is true.

Hello! :)
Indeed it was. You might like what the Plasma Mobile project came up with: https://www.plasma-mobile.org/findyourway/

Sorry if this was posted before, but looks interesting: https://whatcanidoformozilla.org/

What made you step and and decide to contribute to KDE?
I've always wanted to contribute to something. I was very happy with what is going on in KDE lately (Plasma in particular but also the more common apps) and Nate's blog made it seem very approachable, even for someone new to KDE/Qt/C++.

In T8712#159843, @ngraham wrote:

A good next step might be creating a formal Phabricator group for this, to which people could add themselves. Then for example we could document that new contributors should add the group as a reviewer for their first patches, which could help make sure that those critical first patches don't get lost and always have someone available who can help. Thoughts?

Yes. :)

@ngraham are you suggesting to form a group for mentors on Phabricator? If yes, I have some suggestions on that, but we should probably continue this discussion on T8713. Let me know and I'll post my comments there.

Oh, maybe I'm stating the obvious, but the whole patch submission process is absolutely bearable. Nothing fancy. The problem lies more in the way it is explained. Once you have Neon and arc running, it's a breeze.

Thank you so much for taking the time to respond here @acrouthamel . Hopefully as we gather more responses we will be able distinguish some common themes among newcomers' feedback.

A good next step might be creating a formal Phabricator group for this, to which people could add themselves. Then for example we could document that new contributors should add the group as a reviewer for their first patches, which could help make sure that those critical first patches don't get lost and always have someone available who can help. Thoughts?

the only suggestion where people aren't sharing rooms is the french one then :)

The Linux Hotel in Essen-Host (https://www.linuxhotel.de, German only) is are really nice location. I was there once some years ago and forgotten about it :D I ask them today by phone, but they can only host at maximum 25 persons. And this only if several share a two bed room. They proposed to asl "Unperfekt Haus" in Essen Cetrum (https://www.unperfekthaus.de, German only).

Hi Nate,

Yeah exactly, something like that. Where they can git clone (making sure their gitconfig is correct, like how mine wasn't recently), make a branch (and track master), mess it up (lol I've never done that!), submit it via arc diff, tell them how their Git commit is too wordy and needs to break at 80 chars (*ehm* again, never done that before), have someone (newcomer group?) review it and accept it, and then have them arc land it.

In T8711#159319, @acrouthamel wrote:

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

In T8713#159197, @acrouthamel wrote:

I like this, but I feel this should be merged into T8712. The welcome team would make this one of their steps for on-boarding a newcomer.

This is indeed a good idea, I added it as a subtask of T8712.

Much better now. Thanks!

here's an (in danish only, sorry) overview of scouts houses in dk http://hyttefortegnelsen.dk/
but, most require you to be rather scouty, as it is 3 layered bunk beds with 5-6 beds in a room - there's usually a big kitchen (though we would have to cook for ourselves) and only 1 common room, so the work room and eating area would be the same room (unless you want to use the outdoors, which is always dicey with the weather)

In T8712#142246, @simgunz wrote:

The link to the Mentoring page is literally the last word of the Getting involved page.

In T8713#159197, @acrouthamel wrote:

I like this, but I feel this should be merged into T8712. The welcome team would make this one of their steps for on-boarding a newcomer.

Migrating a comment from @schampailler that was posted at T8484#154505:

I was seeing the Kontact prototype website and maybe it could be an interesting first step for this task - an website listing our software related to academia/science/research field.

Together with @stolborg , we are evaluatiing currently two options:

• Les Magnas (France, Provence, Pierrerue): http://auxsaisons.free.fr/
  • 2h by train/bus reachable from Marseilles (nearest airport)
  • how people get from the bus station to the venue ( shuttle service needed)
• local scout huts in Denmark (likely far out and lessluxurious)
  • do we need to cook by ourselfs (I know people, who like to cook for us)
  • how people reach the venue?
  • can people sleep in small rooms?

I was thinking that a way to facilitate a newcomer getting into a project could be to find him a code buddy, another newcomer working on the same project.

What made you step and and decide to contribute to KDE?

• Besides enjoying the DE, it appeared to be a community that was making smart decisions (2017 Goals for example) and was growing.

What was your point of entry to KDE?

• Nate's blog posts basically, and Nate himself.

In what area are you contributing to (development, translation, documentation etc.)?

• Right now a mix of development and bug triaging, with maybe documentation later.

How did you decide where to contribute?

• I decided to work in areas that will help in the 2017 Goals. I like the productivity goal to polish the DE, and I like the onboarding goal to make the project easier to join. Helping a long-time FLOSS project grow is something I'd like to do. Right now my development efforts are small patches, since I'm not much of a programmer right now. Just things I know I can handle. So I'm now focusing on bug triaging, to hopefully assist those who do know how to program well.

What steps did you follow to get involved?

• I started out talking with Nate, he helped me through the 1-2-3 of getting signed up with my various accounts and a dev evironment. He and Henrik recommended some Phabricator Tasks and bugs/feature requests to tackle. Mostly icon fixes, menu edits, stuff like that. From there, I just spent time browsing randomly through Phabricator, finding Tasks and Projects that were interesting. Watching the Activity feed on the right is also helpful to see what cool things are happening and might be worth looking at to offer comments or assistance.

What did you enjoy most in the process of joining KDE?

• The friendliness of everyone, and the ease of joining. There were no trials or tests to go through.

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

I like this, but I feel this should be merged into T8712. The welcome team would make this one of their steps for on-boarding a newcomer.

I'd be glad to help out. This is something that would be a huge help in my opinion. I'm pretty new (I'll answer those newcomer questions shortly), and I know having an easier to find on-boarding group would have been great. Luckily, I found Nate and started bothering him, so it all worked out. But I'm sure a lot of people could use a helping hand to get settled into a KDE project.

I hope not, I'd rather keep it in-house.

I'm sure that there is no need to use Google Calendar after all the effort to move part of release schedule and promo stuff out of it...

Hi everyone just thought I'd drop a note here as well. I've had @sysadmin recreate the Bugsquad, but in Phabricator for easy collaboration. I'd like to resurrect it, with a set schedule of triaging days. I've asked @sysadmin about adding a calendar to the project, or allowing other Calendar edit access. If not, I'll create a Google Calendar people can subscribe to I suppose.

I agree with keeping UNCONFIRMED/CONFIRMED. I was going to make an argument for keeping that as I think it makes sense. Bugs come in, someone looks at it, and reproduces it (or takes other action). So for the triagers I think it makes sense to be able to easily find bugs that have not been reproduced yet.

I would restart from the previous discussion (on kde-community@, and probably elsewhere; for sure it should be discussed on the list).

Done now. So what's next? My sense is that we probably should keep UNCONFIRMED/CONFIRMED now that our bugs are more actively triaged, since there's some value to the distinction.

In T6832#158850, @ltoscano wrote:

Not sure if you did apply the changes already, but in case you did not, please leave open:

• atlantik and atlantikdesigner (on the process of being reimported, one is on git already)
• kgrapheditor is technically part of the released kgraphviewer, even if disabled by default for now iirc, but still "released"

Not sure if you did apply the changes already, but in case you did not, please leave open:

• atlantik and atlantikdesigner (on the process of being reimported, one is on git already)
• kgrapheditor is technically part of the released kgraphviewer, even if disabled by default for now iirc, but still "released"

Actually many these are already closed, and the remaining ones are obviously obsolete and unmaintained (no bugs, says "unmaintained", etc). I don't think there's much of a possibility for problems here. Starting the work. It's easy enough to re-open anything that needs re-opening (but I doubt it).

Thanks so much, @acrouthamel. That list looks sane to me. Anyone else wanna spot-check it?

Ok, I've reviewed the prior list. I've done the following for each product:

• Check Bugzilla for age of any remaining bugs
• Check Git and SVN for age of commits (not created by automated systems)
• Check KDE Wikis for information about unmaintained or obsolete status
• Check Google/DDG for information about unmaintained or obsolete status
• Closed any open bugs left lingering in an unmaintained, dead product.
• Used gut instinct on any that may still be used, removing them from the list

In T6895#157200, @helderc wrote:

@filipesaraiva Are you still here in USP/Sao Carlos? I'm PhD student here...

Ok I'll go through the lists later and get you a definitive one.

@helderc Yes, we still do mentorship programs!
We regularly participate as a mentoring organization in Google Summer of Code, and we have our own mentoring program called Season of KDE ( https://season.kde.org ).
Apart from that, I'm sure the Kile team qill alo be happy to help if you jump on their mailing list.

In T6832#157774, @colomar wrote:

I'm not sure about removing them from Advanced Search, because then people could not find old bugs from them if they are looking for them e.g. for hints towards fixing a similar bug.

In T6832#157770, @ngraham wrote:

Beyond that, it might be a useful change to have products that are closed for new bugs also be invisible on the Advanced Search and Browse lists. This isn't something I can do, and would probably be a sysadmin request. Can you contact sysadmins about that?

I have bugzilla admin powers and can make some of these changes. However I'd prefer to take it slowly and conservatively, so we can avoid any issues.

This would probably have to be done by the KDE Sysadmin team, so we should probably forward this list to them. Right now I am a bit concerned that not everybody might be content with the decision to simply remove all of those from Bugzilla... But then again, all products that would be deleted are unmaintained and the big majority does not have a single bug reported against the product.

Do we have any traction on moving forward with removing these products? Or at least closing them out? What's the next steps?

I would stepup for planing such a sprint.
I've a place in mind in France near Grange Neuve, but I have to find the flyer with the correct name...
I think about doing the print next spring.

Hi @dkazakov, it's great that you are interested and I'm sure your experience would be valuable.

I cannot attend the Akademy this year, but I would really like to join the Autumn sprint. I work on Krita project and I could make a short talk about my experience in working with a university and trying make students involved into our project.

Thanks for responding everyone!

I have no availability for travel this automn (already fully booked until Dec 17), but I could participate in a first BoF session at Akademy.

I'd be interested to attend indeed. Note that I probably won't be able to do the work post-sprint (and trust me there'll be plenty), but I can help devise a path forward during the sprint.

I think this has to be considered an "advanced" topic. We've first got to get the new people submitting patches and having them accepted. I've been banging away at patches and bugfixes for the past 8 months and have never even investigated how to package something for distribution. I'm working on a personal project that I'll want to distribute, but I've got plenty of coding before I get there.

Thanks @sandroandrade , I 'll reach out to the author and try to get some first hand insight on mozilla's procedures and experience.

Some insights that may be useful for our onboarding goal.

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

Hello all, last year during KDE Edu sprint there was a discussion about create an "KDE Research/Science/etc" umbrella for some Edu applications more related to academia works, like Cantor, Kile, KBibTeX, RKward, and others cited in this thread. Maybe this new umbrella could be a motivation to a website or other actions related to this.