<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi!</div><div class=""><br class=""></div><div class="">Kunaal and I had an IRC chat last Wednesday at UTC 0600. We discussed about the new docs toolchain.</div><div class=""><br class=""></div><div class="">The first part of the chat log is about the workflow, here is the summary:</div><div class="">1. user write on local text editor / on github or a web based editor</div><div class="">2. the PR is created on github, and the info is synced to a reviewing platform, where staff discussed about, tag and accept the file</div><div class="">3. if the PR is accepted, the new article is synced from github to <a href="http://git.centos.org" class="">git.centos.org</a></div><div class="">4. new article is deployed and the doc site is updated</div><div class="">5. a tool convert the new article to different formats for upstream projects to use</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span><kunaaljain> hey<br class=""> <yangl1996> hi!<br class=""> <kunaaljain> So did u think anything about project<br class=""> <yangl1996> I think something about the timeline<br class=""> <kunaaljain> tell me<br class=""> <yangl1996> I think by midterm, we should generally finish half of the reviewing platform and the syncing tool<br class=""> <kunaaljain> Reviewing platform is definitely a big task<br class=""> <yangl1996> yes<br class=""> <yangl1996> we can ask on the mailing list for some existing open source project<br class=""> <kunaaljain> We have one and half month for the mid terms<br class=""> <yangl1996> such as some bug tracking platform<br class=""> <yangl1996> yes<br class=""> <kunaaljain> let's see tools required according to workflow<br class=""> <kunaaljain> First user writes a content<br class=""> <kunaaljain> Where does he write it?<br class=""> <yangl1996> I thought about three ways:<br class=""> <yangl1996> 1. he writes on local computer and push it to github<br class=""> <yangl1996> 2. he write on a web-based editor<br class=""> <yangl1996> 3. he write directly on github<br class=""> <yangl1996> do you have other ideas?<br class=""> <kunaaljain> Sounds good to me. Github uses its own github markdown language<br class=""> <kunaaljain> So we adapt that?<br class=""> <yangl1996> oh it is a problem<br class=""> <yangl1996> i have no idea currently<br class=""> <yangl1996> although adapting it will make the language more powerful,<br class=""> <yangl1996> it is not "standard" markdown<br class=""> <kunaaljain> We can use that. its almost standard i think<br class=""> <yangl1996> sounds good to me<br class=""> <kunaaljain> adapting this will help us using github tools<br class=""> <yangl1996> good idea!<br class=""> <kunaaljain> about web - based editor. New editor or existing tools<br class=""> <yangl1996> I think we can use existing tools, because developing a new editor is a huge task in my mind - if we have time after finishing other parts, we can build one<br class=""> <kunaaljain> Yeah, if we have left over time, we will do that.<br class=""> <yangl1996> good idea!<br class=""> <kunaaljain> Okay so content is written<br class=""> <kunaaljain> A pull request has been created on github<br class=""> <kunaaljain> any other option?<br class=""> <yangl1996> yes, totally agreed<br class=""> <kunaaljain> then what happens next?<br class=""> <yangl1996> now that the content is on github, the staff should review it, tag it and comment on it<br class=""> <kunaaljain> Yes but what happens internally?<br class=""> <kunaaljain> Tool wise<br class=""> <yangl1996> maybe the commit should trigger the syncing tool?<br class=""> <kunaaljain> there is no commit yet. Just a Pull Request<br class=""> <yangl1996> so the commit info is synced to reviewing platform<br class=""> <yangl1996> the staff need to review it and comment on it<br class=""> <kunaaljain> Maybe this pull request creates a issue in review platform<br class=""> <yangl1996> yes, exactly what I think<br class=""> <kunaaljain> This review platform helps in tagging and commenting?<br class=""> <yangl1996> yes<br class=""> <kunaaljain> Sounds good to me. Once the content is tagged and commented.<br class=""> <kunaaljain> Changes are made.<br class=""> <yangl1996> yes, the staff accept the new content<br class=""> <kunaaljain> Then there should be an option to commit and close.<br class=""> <kunaaljain> exactly<br class=""> <yangl1996> and the pull request can be merged in the repo on github<br class=""> <kunaaljain> once the commit is made, this is synced to git.c.o<br class=""> <yangl1996> yes<br class=""> <yangl1996> there involves some communication with github<br class=""> <kunaaljain> Yes one way sync?<br class=""> <yangl1996> I think the communication happens in these situations:<br class=""> <yangl1996> 1. github sync commit info to reviewing platform (create a issue on reviewing platfrom)<br class=""> <yangl1996> 2. when staff accept the commit on reviewing platfrom, this actions is synced to github<br class=""> <yangl1996> 3. the one way sync of repo data from github to git.c.o<br class=""> <yangl1996> do you have some ideas?<br class=""> <kunaaljain> Yes. Also the issue needs to be synced i think<br class=""> <yangl1996> yes!<br class=""> <kunaaljain> because staff comments and suggests changes<br class=""> <yangl1996> exactly<br class=""> <kunaaljain> new changes are made on that pull request on github<br class=""> <kunaaljain> these changes have to be reflected on our platform<br class=""> <yangl1996> so this should be a two-way sync<br class=""> <yangl1996> yes I agree with you<br class=""> <kunaaljain> then 3rd point you made is correct<br class=""> <kunaaljain> one way sync from github to git.c.o<br class=""> <yangl1996> yes<br class=""> <kunaaljain> once sync is done, Then new site has to be generated and deployed.<br class=""> <yangl1996> we can use open source tools to do this<br class=""> <kunaaljain> Yes that sounds easy.<br class=""> <yangl1996> Mkdocs<br class=""> <yangl1996> we can use that<br class=""> <kunaaljain> ;) Then upstream projects<br class=""> <yangl1996> :) yes<br class=""> <yangl1996> we use pull model<br class=""> <kunaaljain> here a REST API?<br class=""> <yangl1996> sounds good!<br class=""> <kunaaljain> This will take some time I guess. Totally a new model here<br class=""> <kunaaljain> I don't think previously it has been implemented<br class=""> <yangl1996> yes, we need to build from bottom up<br class=""> <yangl1996> I think so<br class=""> <yangl1996> a have no idea about how open source projects share docs<br class=""> <yangl1996> do they use some special format / conventions?<br class=""> <kunaaljain> I don't think there is such thing till now.<br class=""> <kunaaljain> so we have the basic workflow defined now?<br class=""> <yangl1996> i think so<font color="#ff0000" class=""><br class=""> </font> <kunaaljain> so in basic tool chain<br class=""> <kunaaljain> what else we need<br class=""> <yangl1996> don't know whether we need other parts<br class=""> <yangl1996> do you have some ideas?<br class=""> <kunaaljain> I think what we discussed covers the basic part<br class=""> <yangl1996> yes<br class=""> <kunaaljain> Content writing -> reviewing -> deployment -> upstream<br class=""> <yangl1996> exactly what a doc system needs<br class=""> <kunaaljain> Yes.<br class=""> <yangl1996> here is the ether pad link: <a href="http://etherpad.osuosl.org/CentOS-Docs-toolchain" target="_blank" class="">http://etherpad.osuosl.org/CentOS-Docs-toolchain</a><br class=""> <yangl1996> let's add the workflow to it<br class=""> <kunaaljain> Now I think it is very difficult to divide the proposed tools between us so that we can work independently<br class=""> <yangl1996> so others can know our idea at once<br class=""> <yangl1996> yes, so much dependency between parts<br class=""> <kunaaljain> Yeah definitely<br class=""> <kunaaljain> So What do you think? Working independently or together?<br class=""> <kunaaljain> Is it possible?<br class=""> <yangl1996> if we will work in parallel, we need to define a set of APIs<br class=""> <yangl1996> mainly between syncing tool and reviewing platform<br class=""> <kunaaljain> Defining before start is hard I think<br class=""> <kunaaljain> especially when we don¡¯t know<br class=""> <yangl1996> I think so!<br class=""> <kunaaljain> how reviewing platform will work<br class=""> <yangl1996> yes exactly<br class=""> <kunaaljain> Development of it from scratch is not possible<br class=""> <yangl1996> yes<br class=""> <yangl1996> i am searching for some open source bug tracking platform<br class=""> <kunaaljain> Yes. We can modify it but we need the base<br class=""> <yangl1996> yes<br class=""> <kunaaljain> So either we can work parallel and discuss everyday what we are doing, We can share work and problems<br class=""> <yangl1996> I totally agree<br class=""> <yangl1996> we need to sync our progress frequently<br class=""> <yangl1996> maybe this will be of some use: <a href="http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems" target="_blank" class="">http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems</a><br class=""> <kunaaljain> The list is quite big. You have a look at them, I will too<br class=""> <yangl1996> ok!<br class=""> <yangl1996> and I found centos is now using mantis as bug tracker: <a href="http://www.mantisbt.org/demo.php" target="_blank" class="">http://www.mantisbt.org/demo.php</a> , I will see the features mantis supports<br class=""> <kunaaljain> centos doesnt use bugzilla?<br class=""> <kunaaljain> note that mantis is not open source<br class=""> <yangl1996> oh! that's bad<br class=""> <yangl1996> we need to use open source tools<br class=""> <kunaaljain> no no<br class=""> <kunaaljain> it is open source<br class=""> <kunaaljain> <a href="http://www.mantisbt.org/download.php" target="_blank" class="">http://www.mantisbt.org/download.php</a><br class=""> <kunaaljain> <a href="https://github.com/mantisbt/mantisbt" target="_blank" class="">https://github.com/mantisbt/mantisbt</a><br class=""> <yangl1996> yeah!<br class=""> <yangl1996> about the reviewing platform<br class=""> <yangl1996> how do we implement it<br class=""> <kunaaljain> Ours requirement is not exactly as bug tracking<br class=""> <kunaaljain> we need to interact with github at each point<br class=""> <yangl1996> i agree with you<br class=""> <yangl1996> what we build is a platform syncing data with github realtime<br class=""> <kunaaljain_> I think once<br class=""> <kunaaljain_> we decide on review platform<br class=""> <kunaaljain_> we can divide work and start<br class=""> <kunaaljain_> but we need review platform details first i think<br class=""> <yangl1996> yes<br class=""> <yangl1996> let's discuss in in detail;<br class=""> <kunaaljain_> yeah<br class=""> <yangl1996> what can it do<br class=""> <yangl1996> commenting, tagging<br class=""> <yangl1996> just like github's issue tracking tool i think<br class=""> <kunaaljain_> yes<br class=""> <kunaaljain_> Exactly<br class=""> <kunaaljain_> it is like bugzilla + github<br class=""> <yangl1996> yes!<br class=""> <kunaaljain_> so what we do for this?<br class=""> <yangl1996> can we base the platform on bugzilla<br class=""> <kunaaljain_> bugzilla meets our requirements?<br class=""> <yangl1996> i think no<br class=""> <yangl1996> we need to develop new features<br class=""> <kunaaljain_> what about other platforms?<br class=""> <kunaaljain_> the list you gave<br class=""> <yangl1996> we need to integrate with git, so the choice narrows down a bit<br class=""> <kunaaljain_> so the first task is<br class=""> <kunaaljain_> find a reviewing platform<br class=""> <kunaaljain_> can we do this by today<br class=""> <kunaaljain_> so that we can meet up tomorrow<br class=""> <kunaaljain_> or day after tomorrow again<br class=""> <kunaaljain_> discuss the API and changes in platform<br class=""> <yangl1996> yes exactly<br class=""> <kunaaljain_> and start working on it<br class=""> <yangl1996> ok!<br class=""> <kunaaljain_> Regarding dividing work<br class=""> <kunaaljain_> One option is we work parallel as reviewing platform definitely requries that we both work together<br class=""> <yangl1996> yes<br class=""> <kunaaljain_> so we can work together. the only con is we become dependent. We won;t be able to quantify our individual effort. It will like a team. I am okay with it I think<br class=""> <yangl1996> I am okay, too<br class=""> <kunaaljain_> Great! So let's hunt a review platform fast.<br class=""> <kunaaljain_> Once we finalise that<br class=""> <kunaaljain_> we will work on timeline<br class=""> <kunaaljain_> and then finally start coding :D<br class=""> <yangl1996> ok! I've narrowed down the choice from the list to a few open source projects<br class=""> <yangl1996> :D<br class=""> <kunaaljain_> Great. Keep me informed about the same. I will too look at them :)<br class=""> <yangl1996> with requirement of supporting git and being open source, there are three choices from the list: <a href="http://www.fusionforge.org" target="_blank" class="">http://www.fusionforge.org</a> , <a href="http://www.redmine.org" target="_blank" class="">http://www.redmine.org</a>, <a href="http://trac.edgewall.org" target="_blank" class="">http://trac.edgewall.org</a><br class=""> <yangl1996> and bugzilla<br class=""> <kunaaljain_> okay<br class=""> <yangl1996> I am trying redming<br class=""> <yangl1996> <a href="http://demo.redmine.org" target="_blank" class="">http://demo.redmine.org</a><br class=""> <yangl1996> I registered an account so we can try the demo, login: gsoc_test password: gsoc_test<br class=""> <kunaaljain_> I will try it :)<br class=""> <yangl1996> :D<div class=""><br class=""></div><div class="">----------------</div><div class="">Lei</div></body></html>