|
|
| Line 1: |
Line 1: |
| | <pre> |
|
| |
|
| | * Your name: |
| | * FAS Account: |
| | * Fedora userpage: |
|
| |
|
| =VCS Integration and Project Logging for Waartaa=
| | '''Contact Information''' |
| Denny Scott
| |
|
| |
|
|
| | *Email Address: |
| | *Blog URL: |
| | *Freenode IRC Nick: |
|
| |
|
| ==Contact Information==
| | '''NOTE''': We require all students to blog about the progress of their project. |
| Telephone:204-232-1690
| | You are strongly encouraged to register on the Freenode network and participate |
| | in our IRC channels. For more information and other instructions contact Org Admins. |
|
| |
|
| Blog URL: moonlitestudio.com
| | ''please answer following questions'' |
| | |
| Freenode IRC Nick: dennyscott
| |
| | |
| | |
| | |
| ==Introduction==
| |
| Waartaa mission is to “implement a one-stop open source communication and collaboration tool for teams and groups”. It currently provides a simple and sleek interface to communicate with team members over IRC. As someone who has managed a small development team, handling both communication and collaborative tools is a challenge. Currently, these lines are often disconnected from one another, and require your team to go back and forth between separate tools for communication and collaboration.
| |
| | |
| | |
| One of the next major steps to take with Waartaa is to integrate VCS functions and information. This is already displayed on the Waartaa roadmap, but I believe the best way to do this is to introduce a unique connection between Waartaa and Github. Github was chosen based on popularity, a strong API, and with the understanding that it would be used as the first VCS, building the foundation for later VCS integration. This integration would allow users connected to the Waartaa IRC to view commits, add and edit issues, create comments, etc., in real-time to a connected repository. Furthermore, we could then take the daily Github interactions, and the chat logs, and present them to the users as within a project diary. This diary can be viewed/filtered using tags or dates.
| |
| | |
| | |
| ==Project Goals==
| |
| Create a foundation to build VCS integration with. This should allow other VCS’s outside of Github easy integration afterwards.
| |
| Add (a) github repository/repositories to an IRC channel.
| |
| Automate Organization repository additions.
| |
| Send emails to collaborators of a repo, to inform them of the newly created Waartaa project.
| |
| Display Commits, Issues, repo mentions, etc in IRC chat in real-time.
| |
| Allow users in the IRC to add new issues, milestones and comments through the chat system. If the user is not a collaborator on github, the project owner will be given the option of adding it the next time they log in.
| |
| Develop a Project Diary system. The project diary can be viewed in a number of different ways. You can filter the data by tags(more on that momentarily) or by dates. The diary includes all Github and chat information. The data can be further broken down, allowing users to only view commits, chat, etc.
| |
| Create a tagging system. This way, chat can be organized later for referral. I want to make this part as simple as possible on the user, and plans will be outlined shortly.
| |
| | |
| | |
| ==Implementation==
| |
| ===Building a VCS Foundation===
| |
| Although the initial goal is to develop a VCS integration using Github, the eventual goal is to allow the additions of other VCS’s simply because of a strong foundation. To do this, we build our API structure to use the same call, independent of any VCS. Then, we will judge which VCS system is connected to the project, and make those specific 3rd party API calls, dependent on that choice.
| |
| | |
| | |
| This should make it a much simpler task when adding a later VCS, we would just have to build the same calls to their libraries for the data that we collected through Github. These API calls will be made on the server side, and data collected will be stored in our collections. More on this collection soon.
| |
| | |
| | |
| ===Adding Github Repository/Repositories===
| |
| Each Waartaa IRC could be connected to one or more github repositories. This “Waartaa Project” will then display information and events related to this Github repositories through the chat system as they happen. Adding the repositories to Waartaa will be completed by the owner of the IRC chat, who must be a collaborator on the Github repository.
| |
| | |
| | |
| To check if the user is a collaborator on the Github repository, we will require the user either logs in using OAuth, or provides OAuth information while adding a github repository. When the user is choosing which repositories they would like to add, they can also choose which Github event types that will send updates to Waartaa. For example, they can choose commits, issues, and references, but ignore forks.
| |
| | |
| | |
| Send emails to collaborators of a repo, to inform them of the newly created Waartaa project.
| |
| When we create a project, we could create a link that users can use to log into the system with. This link could be sent to all collaborators of the repositories. The owner would also be able to send further invitations through the VCS of their choice, which in this case would be Github. Meteor already has a simple Mailing package we can take advantage of to handle this task.
| |
| | |
| | |
| ===Display Commits, Issues, repo mentions, etc in IRC chat in real-time.===
| |
| When any event is completed at Github, that information should be relayed into our Waartaa project, to inform us of the event. This can be handled through the Github event API. Further, when that data is collected on our end, collaborators on the repository will be able to alter the “tag” that the event falls under. Tag’s will be explained shortly, but this will allow us to categorize the events, allowing us simpler navigation. Along with the commit and issue data, their appropriate keys must be available, so that users can comment on them simply within the IRC channel.
| |
| Add new issues, milestones and comments
| |
| Users should have the ability to add new issues, milestones and comments to their github without having to redirect their website. By adding this functionality, we ensure that Waartaa is a true one-stop tool for collaboration. Users would have two ways of adding new data to github. They could either type special commands through the IRC chat, or we can direct them to a secondary page where they can manage many of their VCS commands. Since we are using Meteor, all of these additions and commands would be shown to the other users in real time.
| |
| | |
| | |
| Users would also have the opportunity to tag these additions, allowing for seamless navigation when trying to refer back to past changes. It would also streamline a lot of work when it comes to identifying development work on a specific section.
| |
| | |
| | |
| If a user attempts to make an issue, milestone, etc., and does not have the correct privileges on Github, the owner will be notified of their message when they log in. The owner then has a choice if they want to accept these additions. This can be handled with a simple notification system, stored in connection to the users profile. I developed a similar notification system this last year, using Meteor.
| |
| | |
| | |
| ===Create a tagging system===
| |
| This system will primarily be used in connection with Project Diary. It will allow users to “tag” all chat and VCS updates. These tags can then be used when filtering through project diary entries. The owner will have the choice about how open tag creation is. They can choose between Owner only, Collaborator only, or an open tagging system.
| |
| | |
| | |
| One challenge of a tagging system is the annoying side effect of having to tag every single thing you do. To handle this, we offer owners the ability to set a global tagging mode. Additionally, each user can set their own private tagging mode, which takes priority over the global mode. That way, the user or owner can pick a tag to use, and until they change, all entries they make will fall under that tag. Finally, they can also hand code a special pattern into their IRC chat that will tag that single line input as another tag.
| |
| | |
| | |
| Additionally, there will be automatic tags available to the user. These tags will correspond to milestones, commits, and issues. That way, the user has a simple way to connect their conversation to data they’ve collected from github. These will not appear in the github page, but will be used when attempting to isolate information on Waartaa.
| |
| | |
| | |
| We should attempt to make this part as seamless as possible, because it truly is the pinnacle of connecting the communication and collaboration tools. When a user begins typing a tag, if it corresponds to Github data, there should be a popup informing the user exactly what piece of data they are attempting to use. If the tag is part of the Waartaa project, the popup will give some small information on the tag that the owners or other collaborators have used.
| |
| Develop a Project Diary system
| |
| Finally, the fruits of our labour. All of these features are fantastic when your team is attempting to collaborate. But what happens when the user leaves the IRC, or maybe wasn’t there for the original couple conversations on the topic. Rather than forcing these users to scroll through tons of old data, and find each conversation, we create a project diary side menu. This will display the various tags and dates available to the user. The user can simply use this data to filter the chats related to that topic.
| |
| | |
| | |
| This will allow all users the ability to simply go back through the old data and filter the conversation they're looking for. There’s further implications beyond that though. Since we are using meteor, which will be inputting this data in real-time to the project diary, a user can simply use this feature to focus on one conversational piece. Lets say we have a team of 50 users using this single IRC chat. 25 of the members are part of the support team, while the other 25 members are working on a new feature to this product. If both teams are currently having conversations, there are two events:
| |
| 1) Create two separate rooms to have this conversation, making conversational tracking/logging difficult
| |
| 2) Attempt to chat around each others topics.
| |
| By allowing chat filtering through this tag system, users can instead filter conversation to their specific tag at that moment. We then have all chat information stored in one area, and one project diary, but simple separation between teams.
| |
| | |
| | |
| ==Timeline==
| |
| ===Late May===
| |
| Familiarize myself with any documentation that I have not yet understood. I’ve already run through most of the documentation, and have a strong history with Meteor. This phase will be laying the groundwork for what I will need to do at the start of June, so it’s best to get familiar, and discuss with Waartaa exactly how I should be moving forward at this point.
| |
| | |
| | |
| ===Early June===
| |
| Develop the VCS integration system. This will be developed using Github as my primary system, but will be built with expansion in mind. This should have all methods built to correctly send for different VCS events, sending data to VCS, and collecting information.
| |
| | |
| | |
| ===Late June===
| |
| Begin full development using the Github API. This will include adding repositories to the Waartaa project, including building a simple interface to choose which events should be signaled to the Waartaa project. This will also include collecting and sending information to github. Since these functions should already have been developed in the early june, this will be a matter of connecting our first VCS.
| |
| | |
| | |
| ===Early July===
| |
| Complete the Github API, making sure to create new commits, events, etc., both through a simple GUI, and through the IRC messages. Afterwards, I will focus on developing the tagging system. This tagging system will be using extensive amounts of Github API calls for collecting repository information.
| |
| | |
| | |
| ===Late July===
| |
| With all the other pieces in place, I can develop the Project Diary. This will use both the tagging system, as well as a date system to filter the chat logs.
| |
| | |
| | |
| ===Early August===
| |
| This will primarily be used for any additional testing time, and any contingency time, tracing from earlier in the timeline. My intention is to use a very “test-driven” approach throughout the whole project, but it is great to have time set aside for some additional testing and collect more feedback from both the sponsor and any users.
| |
| | |
| | |
| ===Biography===
| |
| I’m Denny Scott, a 4th year student in Applied Computer Science at the University of Winnipeg. I’m from Winnipeg, Manitoba in snowy Canada. I still have another semester at the university to complete my Honours degree. I have a strong passion for web development, particularly in Node Js and Meteor.
| |
| | |
| | |
| I have built a number of projects with Meteor, ranging from an Automated Garden system, using Meteor with Raspberry Pi’s, to an online document sharing system. The document sharing system, called Concloud, was completed this year during work placement with a local construction company, where I was in charge of managing a team of 5 student’s. I’ve also completed a recent portfolio site, built with meteor, and invited some fellow students to join me on there. The portfolio can be found at www.moonlitestudio.com.
| |
|
| |
| | |
| My first experiences with Meteor were back when in was in version 0.4. I can be found in many different places around the Meteor community, including the IRC, and always try to keep up to date. I absolutely love new challenges, and love seeing new development tools. I hope to hear back from Waartaa, and wish you all the best!
| |
| | |
| ==Fedora Questions==
| |
|
| |
|
| ===Why do you want to work with the Fedora Project?=== | | ===Why do you want to work with the Fedora Project?=== |
| I saw the opportunity offered by Waartaa through Meteor's email list, and thought that the technologies I enjoy, and the roadmap they follow are in line.
| |
|
| |
|
| ===Do you have any past involvement with the Fedora project or any other open source project as a contributor?=== | | ===Do you have any past involvement with the Fedora project or any other open source project as a contributor?=== |
| No. This is my opportunity to start! I have many of my own projects listed currently on github, that I have worked with other contributors to build. They are all open-sourced, and available to the public!
| |
|
| |
|
| ===Did you participate with the past GSoC programs, if so which years, which organizations?=== | | ===Did you participate with the past GSoC programs, if so which years, which organizations?=== |
| I have not.
| |
|
| |
|
| ===Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program, if yes, which team(s), you are interested with?=== | | ===Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program, if yes, which team(s), you are interested with?=== |
|
| |
|
| I'm very interested in what Waartaa is doing, and hope to continue contributing to them. I believe that waartaa can grow to be an awesome tool for developers to use.
| | ===Why should we choose you over other applicants?=== |
|
| |
|
| ===Why should we choose you over other applicants?===
| |
|
| |
|
| I have a passion for working on open-source software, and love using Node JS/Meteor. I desire to continue in a web development career and truly believe that I have the skills to develop an awesome collaboration tool.
| | </pre> |
