@Yug Thanks for filing this task! :) I've a couple of questions before I can review the project for new developers guide:

• Could you share the link to the source code, any project documentation (both user and developer) and link to recommended tasks for newbies to work on?

• Who will be the project mentors?

From a quick look,

• When to use issue trackers at https://github.com/lingua-libre , when to use the issue tracker at https://phabricator.wikimedia.org/project/profile/3393/ ?
• Going to the web page https://github.com/lingua-libre/LinguaRecorder , how to find out where to file bug reports? There's no "Issues" tab while other repos like https://github.com/lingua-libre/RecordWizard have an "Issues" tab. I don't really see a pattern?
• As a developer, where on https://lingualibre.org/ could I find info where to find its open source codebase?
• I guess it's not up to any of us but I'd also love WMFR to properly archive https://github.com/wikimedia-france/Lingua-Libre by following https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories , after making the README or description point to the current code base location. T195565#4236022 implies it's archived but I see no signs of that on the webpage.

Previous ticket: T173037: Make my project a Featured Project : LinguaLibre

Hello @srishakatux, @Aklapper
I will answer in the same order as requested :

1. Source code : https://github.com/lingua-libre , which contains several sub projects related to Lingualibre.
2. Mentor : Yug (lead organizer of the project), Poslovitch (lead back end developer). I previously onboarded Poslovitch, who is now a knowledgeable contributor. I also successfully onboarded other users/developers as well in the past, but they mostly moved to other projects since.
3. Issue tracker : github tickets is mainly legacy. New ticket must be open on Phabricator. https://phabricator.wikimedia.org/project/profile/3393/
4. Github issues or not : LinguaRecord is the base js library, very stable for past 10 years. This JS code was a rewriting from C++. Other repositories have their issue open, in case someone wants to ping us on something.
5. Lingualibre.org to codebase : we have no clear pointer on the home page as of now. Our LinguaLibre:Technical_board and our About tab both point to our phabricator and github.
6. Github archive: I followed your recommendation and hard archived this repository.

Thanks for the quick reply (and for archiving the WMFR repo)! Regarding #3, as a new contributor, how to get aware that they are legacy? What does "mainly" mean? How does #3 go together with #4 if issues are open on GitHub, and how would I as a new contributor know that I should report issues in Phabricator, and only use Issues on GitHub "to ping you on something" and not for reporting issues there?

All is not completely clean. When I start coding, I may open a Github issue by habit so to keep track of my progress without clustering Phabricator. I'm reducing this legacy practice tho.
We encourage wikimedian developers to use phabricator. We let non-wikimedian developer interact with us on github issues.
github issues are less active. We periodically migrate issues from github (where we close the issue) to phabricator (where we recreate that issue),

Can do : We can get more explicit with this ticket management approach by explicitly encouraging the usage of phabricator to newbies.
So far, I didn't fell conformtable adding to new coming devs the additional barrier of creating an account on phabricator.
Therefore, I keep Github issues open.

Therefore, I keep Github issues open.

That makes sense, so why are there also tickets in Wikimedia Phabricator then? :) I'm bringing this up as I strongly believe that having several issue trackers is an anti-pattern: It leads to confusion, duplicated work, and fragmentation of conversations. Where is the canonical place that is used for planning future development? (Of course it's possible to have several feedback venues (not: issue trackers), however that can also create the expectation that developers would answer in all and any of them.)

The true issue tracker where we all gather issues is the phabricator. That's where we have it ALL, centralized, organized, tracked. Github is legacy, with occasional activity.
Your feedback helps make the case for a single place of truth. We will push further to phase out Github issues.
(Which should be easy to do since I'am the main holdout XD yet i'm switching to phabricator as well.)
Basically we are phasing out Github issues, this culture change is largely done but still underway.
Do you advise to fully close all our issues tabs on github, at least when we get to zero active ?

Oh, I took the UBN meaning in a large sense of "ongoing / under work right now / next to handle".

That makes me wonder how to better phrase "unbreak now" as there is nothing broken here that needs fixing right now. See "Setting task priority" on https://www.mediawiki.org/wiki/Phabricator/Help for more info (progress could be expressed by someone setting themselves as task assignee or by changing the status)

(Oh.... I see ! https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities thanks !)

I agree with the idea of using just one issue tracker for the project and communicating to incoming or existing contributors about that.

Also, a couple of minor issues that I noticed:

• I see that on the workboard, there are only 2-3 issues right now tagged as good-first-task. It would be helpful to have more perhaps ten such tasks available for new contributors and ensure they adhere to the template here https://phabricator.wikimedia.org/tag/good_first_task/
• The project terms are currently used to name columns, which can confuse someone just arriving on the workboard. Can the column names follow a specific theme - either they convey the type of task (e.g., documentation, design, or research), the progress of the task, etc.

@srishakatux @Aklapper , I added a to do list in the top of that ticket to keep track of your recommendations.

@srishakatux, on our workboard https://phabricator.wikimedia.org/tag/lingua_libre/ ...

I have difficulties to understand "the project terms". Do you mean I should avoid our wiki technolect such as "Gadgets" or "QueryViz" and use more beginner-friendly terms ?

We organized tracks by underlying technical skills and associated field. Example : Backend skills produce the column title Bots, data maintenance/update (via bot), Commons (maintenance via bot)

We are managing a whole wiki, which involves 11 coding repositories, with some additional Common.js/gadget codes, as well as organisational tasks. It involves Lingualibre.org, Wikidata, and Commons. We don't want to have 20 columns either, so we got to be creative and broad in our column naming style, which is unusual.

@srishakatux @Aklapper Timeline / process: also, could you inform me a bit of the process ahead to validate and accept Lingualibre as a feature Apps ? Are your recommendations simple advices, or should we absolutely satisfy those conditions before being accepted ?

Okay, so with project terms, I meant could we have shorter names that are simple? Maybe let's use just one word for column names. The moment I read "File managements, QueryViz, and blah," I am so confused. For reference, see how the columns in two "workboards" are named. They are simple to follow:

https://phabricator.wikimedia.org/project/view/3224/ ,
https://phabricator.wikimedia.org/project/view/782/

So either we use names that tell us about the task type (design, documentation, coding, etc.) or the progress of it (Backlog, in progress, review, done, etc.

For it to become a feature project, I think a few things need more work, and then we might be ready. I don't believe, for example, you need to migrate all Github issues to Phabricator, so we can make it official. Still, you would need to communicate it somewhere where you want incoming contributors to look for tasks and file bugs going forward. Then, I think having a few more good first tasks is essential, and so does making name changes to the column.

Got it. Thank you both for the guidance / mentoring.
I will progress in those directions.
Afterwhat i will check with our team, get us ready, and nag you for the
final push. ,✌🏼

@Hugo Since you were interested in attracting new devs for the project, I thought about letting you know that we have calls for projects and mentors for Outreachy still ongoing in case you and your team members are interested in participating https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/AKMHGVJGK6R2ASUSKK6B64A2SPTXTIBQ/ :)

Still interested yes.
I've been contributing on several other fronts so i havent finished
polishing our Githubs, but we look for new devs yes.
I can do onboarding, yes.

Hi, any news / progress? :) Thanks!

Hello Klapper, thanks for this follow up.
I've been busy with a new IRL work and therefore in Wikipause since
September, my apologize.
As i work by phases to better group tasks and slash them, I expect to
return to Lingualibre this February. This task T311843 is on my to do list.
👍🏼

(➡️ 1. Close or migrate one or two dozen from github issues, 2. Close the a
dozen projects' github Issue tabs ; 3. Edit the related readme.md to point
to Phabricator 4. Send greenlight to you.)

Wish Srishakatux and you good new year. 🌻🎉

@Aklapper bonjour,
I cleaned up Github to phase it out :

• closed issues when possible
• in the README.md, add a Contribute section pointing to phabricator.

I also added feed Good first issue and asked relevant people to add few more.

How do you now assess Lingualibre relatively to the resquest to add it as a Feature project for new developers ?

How do you now assess Lingualibre relatively to the resquest to add it as a Feature project for new developers ?

Hi, I unfortunately cannot answer this as I'm wondering in whose realm this ticket lies nowadays: WMF had some internal changes and Developer-Advocacy does not existing anymore. @srishakatux or @Bmueller may know best which basket this area moved into?

Oh I see.
@Aklapper , is there a new process ?
Either way, could you state something in https://www.mediawiki.org/wiki/New_Developers/Featured_Projects ?
I just submitted T340520 for SignIt, should I close it ? or just add a SignIt vignette in https://www.mediawiki.org/wiki/New_Developers ?
Should the community take over ?