Hi, Over the last week, Lei and I have been researching about the review platform where the content submitted can be reviewed, commented, tagged and pushed. This will be an alternative to github pull requests interface, which will thus reduce our dependency on Github in case Github changes its API anytime in future. Even firefox is considering using Github as an alternative medium to receive contribution. http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/ Lei made a great chart comparing the platforms. https://drive.google.com/file/d/0B9sUy41_Rk3KdGl4RVhDSXZIZmc/view?usp=sharing So overall Bugzilla looks a great option. But there is one major flaw, we need to view the article submitted at each point(code review) which bugzilla lacks. The solution to this is creating a plugin for markdown previewing. The typical workflow might look like this: 1. Author writes content in markdown language. 2. Makes a pull request on github. 3. Corresponding to the pull request a issue is created on bugzilla. 4. CentOS staff can either review the article on github pull request, or on bugzilla. 5. Comments are two way synced. 6. At each point the article can be viewed on bugzilla, using an extension we propose to make. 7. After many iterations of commenting, and improving, article is finally accepted. 8. Staff tags it, and pushes to git.centos.org. 9. Using git.centos.org, new website is generated and pushed. There are many challenging tasks in this, especially the bugzilla issue creation on pull request and two way comment sync. This has never been done before, but we looked at the API and think we can make it work. Another challenging task is markdown preview on bugzilla. Please let us know, what you think about this? Regards, Kunaal -- Regards, Kunaal Jain ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150530/68475738/attachment-0002.html>
On 29 May 2015 at 20:33, kunaal jain <kunaalus at gmail.com> wrote:> > Hi, > > Over the last week, Lei and I have been researching about the review > platform where the content submitted can be reviewed, commented, tagged and > pushed. This will be an alternative to github pull requests interface, which > will thus reduce our dependency on Github in case Github changes its API > anytime in future. > > Even firefox is considering using Github as an alternative medium to receive > contribution. > http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/ > > Lei made a great chart comparing the platforms. > > https://drive.google.com/file/d/0B9sUy41_Rk3KdGl4RVhDSXZIZmc/view?usp=sharing > > So overall Bugzilla looks a great option. But there is one major flaw, we > need to view the article submitted at each point(code review) which bugzilla > lacks. > > The solution to this is creating a plugin for markdown previewing. > > The typical workflow might look like this: > > 1. Author writes content in markdown language. > 2. Makes a pull request on github. > 3. Corresponding to the pull request a issue is created on bugzilla. > 4. CentOS staff can either review the article on github pull request, or on > bugzilla. > 5. Comments are two way synced. > 6. At each point the article can be viewed on bugzilla, using an extension > we propose to make. > 7. After many iterations of commenting, and improving, article is finally > accepted. > 8. Staff tags it, and pushes to git.centos.org. > 9. Using git.centos.org, new website is generated and pushed. > > There are many challenging tasks in this, especially the bugzilla issue > creation on pull request and two way comment sync. This has never been done > before, but we looked at the API and think we can make it work. Another > challenging task is markdown preview on bugzilla.As a word of warning here, not all Markdown parsers and renderers are the same. GitHub's makes a number of additions and changes that go against the original (admittedly vague) spec. This could mean your previews are different and may not match the documentation build. An alternative approach would be to build the docs in CI and link to the built version in a comment on both systems.> > Please let us know, what you think about this? > > Regards, > Kunaal > > > -- > Regards, > Kunaal Jain > > > _______________________________________________ > CentOS-docs mailing list > CentOS-docs at centos.org > http://lists.centos.org/mailman/listinfo/centos-docs >
>> >> Hi, >> >> Over the last week, Lei and I have been researching about the review >> platform where the content submitted can be reviewed, commented, tagged and >> pushed. This will be an alternative to github pull requests interface, which >> will thus reduce our dependency on Github in case Github changes its API >> anytime in future. >> >> Even firefox is considering using Github as an alternative medium to receive >> contribution. >> http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/ >> >> Lei made a great chart comparing the platforms. >> >> https://drive.google.com/file/d/0B9sUy41_Rk3KdGl4RVhDSXZIZmc/view?usp=sharing >> >> So overall Bugzilla looks a great option. But there is one major flaw, we >> need to view the article submitted at each point(code review) which bugzilla >> lacks. >> >> The solution to this is creating a plugin for markdown previewing. >> >> The typical workflow might look like this: >> >> 1. Author writes content in markdown language. >> 2. Makes a pull request on github. >> 3. Corresponding to the pull request a issue is created on bugzilla. >> 4. CentOS staff can either review the article on github pull request, or on >> bugzilla. >> 5. Comments are two way synced. >> 6. At each point the article can be viewed on bugzilla, using an extension >> we propose to make. >> 7. After many iterations of commenting, and improving, article is finally >> accepted. >> 8. Staff tags it, and pushes to git.centos.org. >> 9. Using git.centos.org, new website is generated and pushed. >> >> There are many challenging tasks in this, especially the bugzilla issue >> creation on pull request and two way comment sync. This has never been done >> before, but we looked at the API and think we can make it work. Another >> challenging task is markdown preview on bugzilla. > > As a word of warning here, not all Markdown parsers and renderers are > the same. GitHub's makes a number of additions and changes that go > against the original (admittedly vague) spec. This could mean your > previews are different and may not match the documentation build. An > alternative approach would be to build the docs in CI and link to the > built version in a comment on both systems. >Thanks very much for your advice! We are planning to use Bugzilla, which doesn?t have a built-in code preview function. So we will need to use an external place to provide article review. Building the article in a CI and attach the link on github and reviewing platform would be a great solution. And about markdown standard, it will be a problem to solve.> >> >> Please let us know, what you think about this? >> >> Regards, >> Kunaal >> >> >> -- >> Regards, >> Kunaal Jain >> >> >> _______________________________________________ >> CentOS-docs mailing list >> CentOS-docs at centos.org >> http://lists.centos.org/mailman/listinfo/centos-docs >> > _______________________________________________ > CentOS-docs mailing list > CentOS-docs at centos.org <mailto:CentOS-docs at centos.org> > http://lists.centos.org/mailman/listinfo/centos-docs <http://lists.centos.org/mailman/listinfo/centos-docs>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150531/600354d3/attachment-0002.html>
>> >> Hi, >> >> Over the last week, Lei and I have been researching about the review >> platform where the content submitted can be reviewed, commented, tagged and >> pushed. This will be an alternative to github pull requests interface, which >> will thus reduce our dependency on Github in case Github changes its API >> anytime in future. >> >> Even firefox is considering using Github as an alternative medium to receive >> contribution. >> http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/ <http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/> >> >> Lei made a great chart comparing the platforms. >> >> https://drive.google.com/file/d/0B9sUy41_Rk3KdGl4RVhDSXZIZmc/view?usp=sharing >> >> So overall Bugzilla looks a great option. But there is one major flaw, we >> need to view the article submitted at each point(code review) which bugzilla >> lacks. >> >> The solution to this is creating a plugin for markdown previewing. >> >> The typical workflow might look like this: >> >> 1. Author writes content in markdown language. >> 2. Makes a pull request on github. >> 3. Corresponding to the pull request a issue is created on bugzilla. >> 4. CentOS staff can either review the article on github pull request, or on >> bugzilla. >> 5. Comments are two way synced. >> 6. At each point the article can be viewed on bugzilla, using an extension >> we propose to make. >> 7. After many iterations of commenting, and improving, article is finally >> accepted. >> 8. Staff tags it, and pushes to git.centos.org. >> 9. Using git.centos.org, new website is generated and pushed. >> >> There are many challenging tasks in this, especially the bugzilla issue >> creation on pull request and two way comment sync. This has never been done >> before, but we looked at the API and think we can make it work. Another >> challenging task is markdown preview on bugzilla. > > As a word of warning here, not all Markdown parsers and renderers are > the same. GitHub's makes a number of additions and changes that go > against the original (admittedly vague) spec. This could mean your > previews are different and may not match the documentation build. An > alternative approach would be to build the docs in CI and link to the > built version in a comment on both systems. >Thanks very much for your advice! We are planning to use Bugzilla, which doesn?t have a built-in code preview function. So we will need to use an external place to provide article review. Building the article in a CI and attach the link on github and reviewing platform would be a great solution. And about markdown standard, it will be a problem to solve.> >> >> Please let us know, what you think about this? >> >> Regards, >> Kunaal >> >> >> -- >> Regards, >> Kunaal Jain >> >> >> _______________________________________________ >> CentOS-docs mailing list >> CentOS-docs at centos.org <mailto:CentOS-docs at centos.org> >> http://lists.centos.org/mailman/listinfo/centos-docs >> > _______________________________________________ > CentOS-docs mailing list > CentOS-docs at centos.org <mailto:CentOS-docs at centos.org> > http://lists.centos.org/mailman/listinfo/centos-docs <http://lists.centos.org/mailman/listinfo/centos-docs>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150531/15299561/attachment-0002.html>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/29/2015 12:33 PM, kunaal jain wrote:> Hi, > > Over the last week, Lei and I have been researching about the > review platform where the content submitted can be reviewed, > commented, tagged and pushed. This will be an alternative to github > pull requests interface, which will thus reduce our dependency on > Github in case Github changes its API anytime in future.Definitely I agree with that thinking. One thing to consider is that some people may us the pull request model and then not want to go further outside of the tool. One way to think of this is to see if you can work with someone entirely in GitHub, if that happens, maybe by having the content reviewer do the shuffles with bug tracking.> Even firefox is considering using Github as an alternative medium > to receive contribution. > http://gregoryszorc.com/blog/2015/01/12/utilizing-github-for-firefox-development/> > Lei made a great chart comparing the platforms. > > https://drive.google.com/file/d/0B9sUy41_Rk3KdGl4RVhDSXZIZmc/view?uspsharingWere>you able to compare with Mantis, which is what runs http://bugs.centos.org? What are the time implications with connecting to a bug/task tracking tool? I'm glad you are thinking about this at the start, in case you also use GitHub in parallel with git comments and pull requests, as a way to get a minimal feature set running. I'll comment in other parts of this thread, to keep context. Regards, - - Karsten> So overall Bugzilla looks a great option. But there is one major > flaw, we need to view the article submitted at each point(code > review) which bugzilla lacks. > > The solution to this is creating a plugin for markdown previewing. > > The typical workflow might look like this: > > 1. Author writes content in markdown language. 2. Makes a pull > request on github. 3. Corresponding to the pull request a issue is > created on bugzilla. 4. CentOS staff can either review the article > on github pull request, or on bugzilla. 5. Comments are two way > synced. 6. At each point the article can be viewed on bugzilla, > using an extension we propose to make. 7. After many iterations of > commenting, and improving, article is finally accepted. 8. Staff > tags it, and pushes to git.centos.org. 9. Using git.centos.org, new > website is generated and pushed. > > There are many challenging tasks in this, especially the bugzilla > issue creation on pull request and two way comment sync. This has > never been done before, but we looked at the API and think we can > make it work. Another challenging task is markdown preview on > bugzilla. > > Please let us know, what you think about this? > > Regards, Kunaal > > > -- Regards, Kunaal Jain ?? > > > > _______________________________________________ CentOS-docs mailing > list CentOS-docs at centos.org > http://lists.centos.org/mailman/listinfo/centos-docs >- -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVslN4ACgkQ2ZIOBq0ODEGrBQCggSwF5XlvvVoxquhk2HHp8F7k z8oAoJxoO7etPolWuN+eeut9NWMX7ptS =pwGB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/30/2015 09:19 AM, Dougal Matthews wrote:> An alternative approach would be to build the docs in CI and link > to the built version in a comment on both systems.This is an interesting idea. We'll end up wanting docs to build in the CI anyway, so this could be done using e.g. a -draft tag so an initial commit can be used to both build drafts and help with the review process, then transition to not-draft. We'd still have MarkDown preview in GitHub, but also have a version rendered with the toolchain so we can also be debugging build problems as well as content itself. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVslWEACgkQ2ZIOBq0ODEEplQCfaIyGOTJ4elJK6aENHU5mvkfk OwUAni8y8loHZjtbN+pReYL1A4wXgDZB =fueA -----END PGP SIGNATURE-----