Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crafting and discussion of the team's plan #1

Open
renatomassaro opened this issue Jun 28, 2017 · 2 comments
Open

Crafting and discussion of the team's plan #1

renatomassaro opened this issue Jun 28, 2017 · 2 comments

Comments

@renatomassaro
Copy link
Member

The purpose of this task is to figure out how to achieve objectives described on the statement page.

@renatomassaro
Copy link
Member Author

For starters, we have one "logistics" problem due to how Github works. While it's important to centralize the Development Team into a single repository, its tasks and discussions are spread among several more specific repositories, like Helix, HELF and HEBorn. As such, we can't expect issues on one of these repositories to be automatically "replicated" into the Development one.

In order to efficiently achieve "a clear way for potential contributors to pick specific tasks based on type, difficulty and language", I think we should keep these specific repositories properly tagged and up-to-date, and only use the Development repository to guide contributors to specific projects.

I mean, a first-time contributor wanting to help with code would possibly visit the Development repository first. Then, she learns about each specific project and can pick one more suitable for her. This high-level introduction to the different projects allows her to select 1) what language/paradigm she's more familiar with, or more willing to learn, and 2) what kind of software project she is more fond of. Maybe she likes backend stuff. Maybe she's more of a frontend person.

So one extra goal/chore/task of the Development team would be to make sure issues on specific software projects are always properly tagged and accounted for. Then, this repository's issues could be used for higher level management, planning and discussions.

We could also keep a list of interesting tasks of each specific software at the Status page. However it's not possible for it to be either extensive or always up-to-date.

@renatomassaro
Copy link
Member Author

Another thing I'd like to point out is the need for a RESOURCES.md. This file, which should be a joint effort with the Documentation team, is supposed to have a curated list of resources contributors can use to learn the programming languages and other technical details we use daily.

I believe the resources file, as well as mutual help from learning contributors, are a major step towards our goals. Discussion of resources is at #2.

Let me emphasize this: if two or more contributors are studying a specific language/technology, we should definitely put them together so they can share insights, questions and answers. Sort of a "study group". I have no idea how we could make this happen, and this would need to be a 100% community-powered effort, but I believe it would be extremely beneficial to the students if they could learn together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant