---
# System prepended metadata

title: Radicle project

---

# Radicle project


## Hiring
* **Top priority**: Tech Lead hire (Rust experience + systems programming)
* **Top priority**: Designer hire for product (Web & CLI) (possibly have candidate)
* very clear job description (what is the project about, what are the goals, what is used in the stack, what type of individual we are searching for, where they should send their CV and cover letter (jobs@radicle.xyz) and have it posted on radicle website as well (either jobs.radicle.xyz or radicle.xyz/jobs)
* for this size of a project and the current workflow I would suggest monthly posting on the Hacker News, fossjobs and posts to debian-jobs (and similar), to rustlang (they likely have job ML as well), golang (and so on)
* resumes should be checked, especially connections to previous work (open source if possible)
* good habit is to have a ready template for two types of replies: one that is rejecting and the other that is asking for their availability for the interview
    * there should be one structured interview, for around an hour (I would say 15mins to see social/cultural fit and 45mins quite technical)
    * after this it can be max one more, rejection or acceptance (which goes to the hiring manager for salary discussion etc)
		
## Onboarding
* **Top priority**: make onboarding easy, not require too much extra work every time we hire/onboard
* general onboarding doc (this is radicle, here are docs (infra, mails, chat, important docs about relationship between radicle and contractor, tools used, 2FA, sharing secrets/access)
    * specific doc to the domain: web, core, non-technical etc
    * one doc for contributors, one for contractors

## Process
* **Top priority**: daily reports (in the daily report channel)
* timelog (I know we discussed this, but for people hired by radicle, this should kinda be a deal because it makes all the difference is radicle trying to be a project only or an eventual product) ```timelog might be hard as people are contracted in different ways (days vs hours). I see the channel for absence tracking but it should be done better```
* weekly 1on1 with the project manager
* potential once a week standup (this is also a difference that radicle needs to decide - project or an eventual product)

	
## Project Management
* **Top priority**: Zlatan meets team
* utilize github for nice lists, boards and milestones
* issues should have start and end dates if we want to have proper roadmaps and milestones
* chat is good but discussion inside issues should be fostered to have a trace to everything
* skills matrix to know who is capable in what area, in which features, ideas and roadmaps can have a base
* doing 1on1 with people, looking into their wellbeing and personal development, removing blockers

	
## Approach to community
* **Top priority**: HACKING.md / (PROJECT.md?)
* depending on how radicle wants to develop, there are two ways:
    * full open source project that is trying organically to grow (exposing the project slowly through various conferences, networking (word of mouth))
    * open source project that is also a product of the company (radicle foundation) - the project has the backing of the foundation so it is a mix of paid and normal contributors. Sponsor open source conferences, attract talented people, foster wider discussion that can turn into ideas for features or changes, bounty issues, sponsoring development that we might depend on, hackatons

There needs to be a clear document on how and where to contribute, otherwise the lack of structure is not going to attract the best from the community.


## Social media and blogging
* **Top priority**: Hire? Start tweeting?
* developers should blog about their work (they should own and be proud of their work, so blogging shouldn't be an issue), blog about major changes, features, sponsorships, conference attendance and talks, collaborations, community updates etc
* social media should just relay what is written on the blog (one needs to be careful to not tweet etc too much of non-important things, but rather very related things)
* ghost blog is a good open source blogging platform that is usable for non-technical users


## Conferences
* **Top priotity**: Make a plan, identify some conferences to talk at
* fosdem (maybe sponsor, for sure submit a talk)
* debconf (sponsor, be part of swag maybe, this year it is in India)
* las (sponsor, maybe submit a talk)
* ccc (and all minor ones around it) (not sure around sponsorship, for sure submit a talk)
* bornhack (and all similar ones)(sponsor, submit a talk)

	
## Misc ideas

While everything is remote, radicle might setup a physical hacklab that could attract users and developers from around the world but also be a place for hosting conferences, hackatons etc

I should probably be added to github projects to do the actual project management.

Why the MIT/Apache license instead of GPL?

Radicle roadmaps/feautres should be around stabilizing the core product first and then catching up with features with Github. Gitea as an open source project might be a good inspiration as well.

Runn has a good [career website](https://www.runn.io/careers) to attract their future hires: . Radicle might learn from it.

103 repos on the Radicle github seems to be a bit of overkill - can that list be cleaned?

A user howto, with nice screenshots/gifs would be very helpful if you want see people using it - github became popular because it created nice visual aspect aroun git (there were git providers before github, but none captured it well for newcomers/non-Linux users as github did - radicle should strive to the similar levels)