Fill out missing sections of the constitution:

[MElemental]

Article IV Section II and Section III

[calebjpicker]

@MElemental , I recommend we re-organize our current constitution so that it follows the outline provided by UNLV:

UNLV Writing a Constitution Guideline

[MElemental]

@MElemental , I recommend we re-organize our current constitution so that it follows the outline provided by UNLV:

UNLV Writing a Constitution Guideline

On a related note, we can actually make seperate documents and include them into a main document in org-mode.

To do this we would use org-mode's include syntax:

#+INCLUDE: "filename.org" or #+INCLUDE: "path/to/file.org"

For example our constitution org document could look like:

#+TITLE: Tabletop Organization for Data Analysis Constitution

* Article I

#+INCLUDE: "Name.org"

* Article II

#+INCLUDE: "Purpose.org"

...simile... 

This will insert the respective document in the file. This should make it easier to move content around.

[calebjpicker]

How will it know which sections we want to insert?

I was also talking with Jordan today and told him about our Git Flow. He says that the way he does it is that he has one develop branch per developer. I believe that each developer would then merge into a main 'develop' branch.

[MElemental]

I think we should organize our gitflow by task. Such as a constitutional branch for working on constitution stuff. A database for adding a database. etc.

For your question, we have to make a name.org file, an Purpose.org file, a membership.org file, etc

[MElemental]

I was also talking with Jordan today and told him about our Git Flow. He says that the way he does it is that he has one develop branch per developer. I believe that each developer would then merge into a main 'develop' branch.

The nature of this project is different from a software project. I think we should be focusing on task instead of individual streams of contributions. hence the constitutional branch, the database branch etc. eg

key:
o= commit
/, \, or | = branch or merge 

                             Constitution----------o----------------------------------------
                           /                                /
Develop----------o------------o-----o-----o----------o----------------------o-------
                          \                       /                        | Release
                          DataBase-----o-------------------------------------------o------
                                                                           |
Master ------------------------------o------------------o--------------------------o--

[calebjpicker]

I believe these ideas are not mutually exclusive. Each Project is a 'feature' that is a branch from the develop branch. I can imagine there may be scenarios where we are working on the same document at the same time--how do we account for merging conflicts? One way is to have one develop branch per developer.

[calebjpicker]

How will it know which sections we want to insert?

I was also talking with Jordan today and told him about our Git Flow. He says that the way he does it is that he has one develop branch per developer. I believe that each developer would then merge into a main 'develop' branch.

While I understand the spirit of this idea, I believe it is too time-consuming and burdensome.

[MElemental]

It's going to tell us to resolve conflicts either way. I don't think we should be working on the same files at the same time. We should assign people to specific features at certain times, use the pull requests to propose changes, then finalize at a certain time to merge all feature branches to develop.

[calebjpicker]

It's going to tell us to resolve conflicts will need to resolve either way. I don't think we should be working on the same files at the same time. We should assign people to specific features at ceratain times, use the pull requests, then finalize at a certain time.

For example, we are both working on the Constitution now, right? This is a big project that requires multiple people to work on it at the same time. So I think it's better to have more flexibility in who can work, when they can work, and on what they can work.

Can you tell me a bit more about how these pull requests work? Who should be making the pull requests? Is it the person who finishes a feature?

[calebjpicker]

I just want to be sure that we don't accidentally overwrite any of our work. I think if we do pull requests, that issue can arise. For example, one of us may merge a pull request from the same branch we are working on. If that work wasn't committed, that work is lost.

So is there a more robust method we can use to ensure something like that doesn't happen?

[MElemental]

I'm separating the constitution into separate files on my local repository. This will allow us to edit each section separately and have changes automatically update the main constitution file which links all of the other files.

We should learn pull requests for those instances that we do have to edit the same file. Pull requests allow us to discuss changes instead of just editing a file hoping we don't conflict with each other. Pull Requests

I do apologize for experimenting with the pull requests. I was not using them optimally. Pull requests are suppose to be collaborative, it would be making a thread like this except with edits weaved in.

[calebjpicker]

I'm separating the constitution into separate files on my local repository. This will allow us to edit each section separately and have changes automatically update the main constitution file which links all of the other files.

We should learn pull requests for those instances that we do have to edit the same file. Pull requests allow us to discuss changes instead of just editing a file hoping we don't conflict with each other. Pull Requests

I do apologize for experimenting with the pull requests. I was not using them optimally.

I certainly understand the method you are talking about--it just seems so cumbersome. I feel like there must be a more robust method.

I have read the Pull Requests document. However, I believe we would only use pull requests when merging our own forks into the main branch, no? That is, we cannot both work in the same branch and perform a pull request on it. We'd have to work in a separate branch.

No need to apologize. I'm trying to figure this out, too.

[calebjpicker]

Maybe we just make a fork each time we work on the same document or within the same branch. Then when we are done, we create a pull request to merge the changes. Oh, that's it!!

[calebjpicker]

So there'd be a 'Constitutional-Caleb' branch and a 'Constitutional-Rudy' branch. We continue to work on it until we are ready to commit to 'Constitutional'. At that time, we create a pull request, and the other person will review it.

[calebjpicker]

Basically, we should never directly commit to 'develop'. Using pull requests, we should only commit our own separate 'feature' branches to a 'feature' branch, and then commit the 'feature' branch to the 'develop' branch.

[MElemental]

It's actually a lot less cumbersome than you think. Object Oriented Programming's principle of encapsulation dictates that you separate programs into smaller chunks then call the function from the main program.

Daina Chiba does it in his LaTeX source code for his mahjong book. https://github.com/dainachiba/RiichiBooks/blob/master/RiichiBook1.tex

fork means that I copy the repository to my account then edit it on my account. normally someone would make a pull request of their fork. We don't want to be doing that everytime to do a pull request.

[calebjpicker]

Why do you think we shouldn't fork or branch and then call pull requests to merge changes?

I feel like this solves this and all future problems. We don't want to have to encapsulate all our documents all the time.

[MElemental]

don't use fork and branch interchangeably, they mean significantly different things. fork implies having a whole copy of this repo on my account, that can later get submitted as a pull request. This is usually for bigger projects.

Branch means another branch in this repository

I think we do want to encapsulate all Articles in the constitution. This way we can edit the primary structure in "TODAConstitution.org" and edit the contents in the Article files. That is significantly more useful and powerful than continuously branching from feature branches.

Having seperate branches is not going to solve our conflicting changes problem.

if I merged my branch first with a pull request first, then you merged yours, It would be the same as if I edited the main feature branch directly. We would still be resolving conflicts.

We should be using pull requests to collaborate on feature branches. Pull requests are supposed to be optimized for communicating and tweaking changes.

[MElemental]

I was wrong about github being able to interpret #+include: in org-mode. My Encapsulation approach won't work on github.

However we should still investigate pull requests especially if the encapsulation approach won't work.

[calebjpicker]

don't use fork and branch interchangeably, they mean significantly different things. fork implies having a whole copy of this repo on my account, that can later get submitted as a pull request. This is usually for bigger projects.

Branch means another branch in this repository

I think we do want to encapsulate all Articles in the constitution. This way we can edit the primary structure in "TODAConstitution.org" and edit the contents in the Article files. That is significantly more useful and powerful than continuously branching from feature branches.

Having seperate branches is not going to solve our conflicting changes problem.

if I merged my branch first with a pull request first, then you merged yours, It would be the same as if I edited the main feature branch directly. We would still be resolving conflicts.

We should be using pull requests to collaborate on feature branches. Pull requests are supposed to be optimized for communicating and tweaking changes.

Even if we merged at different times before resolving a pull request, we'd be able to resolve the conflicts through the pull requests. However, if we edited the main feature branch directly, we may not even be aware of any conflicts.

Like you said, pull requests are optimized for communicating and tweaking changes, and we can use them to collaborate.

[MElemental]

Even if we merged at different times before resolving a pull request, we'd be able to resolve the conflicts through the pull requests. However, if we edited the main feature branch directly, we may not even be aware of any conflicts.

There wouldn't be conflicts we wouldn't be aware of. I'm concerned with having a bunch of duplicate branches, where we retread over the same ideas. I'm also worried that having independent developer branches will cause a lack of communication between the developers that are working on a feature.

Perhaps we should work this out IRL and figure out what the actual issues are.

[calebjpicker]

I essentially filled out the rest of these sections. I will put these changes into a pull request that you can then review. Please commit any new changes to the pull request I create.

We may also need to give the Constitution another look through to make sure we still agree with everything and to ensure that all language is consistent throughout all sections.

[MElemental]

We should go over this constitution section by section

[calebjpicker]

I agree.

Duplicate of #42 , so I am closing.