search

devguilds / fcc-community

Our goal is to bring the FCC community together by providing an easier way to share and join meetups, events, and GitHub projects.
MIT License
13 stars 5 forks source link

How to work on this project? #5

Closed AlexandroPerez closed 7 years ago

AlexandroPerez commented 8 years ago

So its been kind of slow trying to get the Share Collaboration going. I'm sure that for the most part is due to most members (including me) not having enough experience. We could however make a list of the skills that will be required to build this project, and provide a plan of the the work ahead, so each member knows what to prepare for.

So far I believe we can all agree to have an app that will be:

What are your thoughts about this process? What is being missed, or in what other way should we handle the project?

anhle128 commented 8 years ago

great ! I can't wait to see it

JimmyBonez commented 8 years ago

Very cool idea, and would like to be part of this, if that is possible?

AlexandroPerez commented 8 years ago

@JimmyBonez Yes! Everyone is welcome to collaborate. The purpose of this and upcoming projects is to learn how to collaborate and work as a team in GitHub, so everyone from newbies to advanced (even outside Free Code Camp) are welcome to join us.

Feel free to join us in gitter as well.

ninjakimal commented 8 years ago

i would love to join this journey too!

stellapelagatti commented 8 years ago

I´m UI/UX designer, and I´m really interested to be part of this! Cool idea!

sapioit commented 8 years ago

Could you, please, put this in a project of itself, so people could start, fork and come with pull requests? The idea is great, but there is place for better execution. Also, a generalisation would be highly recommended.

sapioit commented 8 years ago

By generalisation I mean the tools should be kept aside (that means not having MongoDB, but SQL mentioned, not having Node.js but Back-End mentioned. Sure, at the back end could be more than one language, but I think there is need for soemthing like this, just more... "Universal"...

lsavage92 commented 8 years ago

Is there a reason why you would want to have a "generalization"? The technology you have mentioned is listed under the general sections you also mentioned. I think the reason we chose the front end stack because it will work nicely with a component based workflow allowing for strong parallelization of contributions. The back end is more up for debate, but I'm pretty sure it was chosen to be Mongo/Express because most people coming from FCC will have a background in Javascript making it easier to move forward without having to learn another language (python/django or ruby/rails, etc)

lsavage92 commented 8 years ago

I propose that we use our waffle.io board (or trello if we are moving there) and we just start throwing user stories in an icebox until we have a good baseline. Once we have that, we can start to prioritize stories/features and mark up any features that are dependent on others. This way we will end up with a backlog of work that is well organized and ready for people to pick up and go.

It may also help for us to have separate boards for front-end tasks and back-end tasks to make it easier for people to stay organized.

sapioit commented 8 years ago

It may also help for us to have separate boards for front-end tasks and back-end tasks to make it easier for people to stay organized.

In which case we would need something to couple the front-end with the back-end, do you not agree?

Sure, there are people who only know front-end and people who only know back-end, but there are far more people (and better paid) who understand both things. Sure, they might not be able to do much in one, but they know how stuff works or what should and what should not be possible/easy/difficult/insert_somethin_here.

What I mean is that the repo (which I hope will be created) would be a template ready to be customised by other projects. You could call the files development-process.md, front-end-development-process.md and back-end-development-process.md, for example or for the beginning, to make them something "universal", and applyable to any project.

Also, from the backend list PHP is missing, Ruby and RubyOnRails are missing, Python is missing and many more.

sapioit commented 8 years ago

Also, by having it a separate repo, it would be much easier to just include the files in every new project.

lsavage92 commented 8 years ago

In which case we would need something to couple the front-end with the back-end, do you not agree?

The only coupling we would really need is an agreement on the API, unless I'm misunderstanding, in which case please expand 😄 . And I'm in no way implying that people don't know both ends of the stack (I personally work as a front-end software engineer who can also work back-end). I'm not sure what that has to do with having separate boards to organize tasks.

The lists that Alexandro has put up were from the tech stack that we had previously discussed and settled on for the application, not the existing tech for that particular paradigm. I suppose they are up for debate if there are compelling reasons to change.

marcywilliamspudalov commented 8 years ago

I'm really interested in being a part of this too!

sapioit commented 8 years ago

I get what you mean, but in order to work for a small group, they should also be able to work for a bigger group By coupling both ends of the spectrum (front-end and back-end), you allow a deeper understanding of the product you're trying to build. If you offer it as a template, people are sure to come and make modifications to fit their current project's needs. Currently, this is focused on front-end with some back-end combined, and that goes against the future of the idea you presented us with.

taylorpage commented 8 years ago

I'm not sure what you're talking about to be honest. I think you may be over complicating something that should not be. On Jun 16, 2016 9:59 AM, "sapioit" notifications@github.com wrote:

I get what you mean, but in order to work for a small group, they should also be able to work for a bigger group By coupling both ends of the spectrum (front-end and back-end), you allow a deeper understanding of the product you're trying to build. If you offer it as a template, people are sure to come and make modifications to fit their current project's needs. Currently, this is focused on front-end with some back-end combined, and that goes against the future of the idea you presented us with.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fcc-community/fcc-community/issues/5#issuecomment-226511698, or mute the thread https://github.com/notifications/unsubscribe/APEARrMIPmX_Xekm1mz1aDE2pmMI0nGnks5qMWTbgaJpZM4I3GnA .

lsavage92 commented 8 years ago

@sapioit I think I understand what you're saying now. Are you suggesting that we take the original comment that came with the issue and upload it to the repo as a .md file so we can edit it via PR?

sapioit commented 8 years ago

Yes. And if we have a new repo to work on the original comment in order to make it better, new projects could use the new/better version, while the existing projects would not need to update. I am thinking of it as a template ready to be customised with the project's "blood and bones", allowing a new developer to jump right in without having to read a good part of the existing code-base.

For example, a project would require having the front-end code separated form the back-end code (in a different set of files), while the back-end would load that file and populate it with meaningful data. Another project would require the front-end code to be mixed with the back-end code. You could explain that and the structure of the back-end and front-end in this file, without going into details such as how it is working or why is it implemented the way it is (that's the job of the code comments and documentation blocks).

You could explain that in this folder with 100 small files, X,Y,Z and T are used for the API which is the file Q, while T, Z, J, K, P, L and D are the dependency of the control panel, but Q and W are used for the par of the application which (for example) returns something to the viewer (not user, no credentials (user/pass/key/etc.) required).

sapioit commented 8 years ago

But all of those things could begin from a generalised template containing... whatever the template starting from this comment will end up as...

lsavage92 commented 8 years ago

Okay so I totally agree that we should have the "universal" .md file to start from and I think it should be uploaded to this repo since this is the main one. One thing I'm still unsure on is what you mean when you are talking about different "projects". Are you meaning the different features? (calendar, scheduling, groups) It's a little ambiguous here.

Law78 commented 8 years ago

I would like to join with you!

sapioit commented 8 years ago

I mean this different projects. Like maybe different sites, or different parts of the same site... or even different features of the same part of the same site, that require different repos.

AlexandroPerez commented 8 years ago

@sapioit I think I have a good understanding of what you're suggesting. Since the focus of this project is to bring developers together (from newbies to advanced) and learn to collaborate in different projects (this being the first) we should create a "barebones" repository with .md files for the different development processes, that will serve as the initial setup for future projects.

sapioit commented 8 years ago

Yes, but with a limited ammount of .md. For example, development.md (the more in-depth version of the following two files together), front-end-development.md, back-end-development.md in the main directory of the repo, and a bunch of folders each with a different implementation of those files accordingly with the example project, maybe also some other .mds, depending on the project.

zenware commented 8 years ago

RESTful API's can output JSON data. Also, I'm not so sure the setup needs to be quite that bureaucratic... I guess we'll see where it goes.