On 6 December 2012 09:43, Dan Allen <[email protected]> wrote: > inline... > > On Tuesday, December 4, 2012 3:51:56 PM UTC-7, Lex Trotman wrote: >> >> Hi Manfred, >> >> On 5 December 2012 08:34, Manfred Moser <[email protected]> wrote: >> > Related to that I have noticed that the github asciidoc name is taken >> > and >> > an asciidoc maven plugin exists there. >> > >> > I think it would be great if asciidoc itself would push to a repo there >> >> Well if someone (tm) were to create a mirror repo with the hg history >> imported then that would be a start. > > > +1 > > Even if it's just a mirror, GitHub provides great visibility for projects. > Many organizations, such as Apache, mirror there even if they don't use it > for the primary hosting. >
Yes, having a mirror can be a good first step to moving to github. >> >> >> > and accept pull request via github. >> >> (OT slightly) I find the PR interface on Github laughably naive, no >> reasonably responsible committer is going to commit a PR by clicking >> the button without testing it first, by applying it to a working dir. >> But applying it to a working dir is a messy workflow involving either >> a transition via patches or having to continually adjust the remotes >> of your local clone :( </rant> >> >> But the pr process does seem to encourage submissions. > > > I agree, quirky or not, the GitHub user interface is working when it comes > to attracting more participation. The numbers clearly show it. > > Btw, the "clicking the button without testing it first" is solved rather > elegantly by Travis CI, which integrates directly with GitHub. We use that > in the Awestruct project and no longer sweat over the merge button. > Sadly this doesn't support any of the languages, systems or workflows I need. >> >> >> >> The same organization could be used as >> > an umbrella for other asciidoc related tools similar to e.g how Hudson >> > has >> > a project for all its plugins and so on. >> >> I'm not so sure about this, my experience from another project with >> plugins under the umbrella of the main project organisation, is that >> either plugins are "dumped" and left to the main devs to maintain, or >> that there are issues around stability and reliability of the plugins. >> But being under the umbrella of the main project, it gets the blame >> for plugin problems. > > > This could go either way, it really depends on the community. We use the > model with great success in the Arquillian project. We don't mandate that > modules / add-ons related to Arquillian be there, but instead they often > request to be for the increased visibility and feeling like they are part of > the team. > Yes, but ... if something is submitted and then the maintainer can't continue and noone else wants to do anything on it, what does the project do? Since it was part of the project people started using it and will be unhappy (or outright and volubly cranky) if it is removed because it has bit rotted and isn't compatible with the current asciidoc. > I think it's a great idea to have the http://github.com/asciidoc > organization host both the main source code (under the project asciidoc) and > any other modules / add-ons that would like to be there. Of course, addons > can be hosted elsewhere too, and there's nothing wrong w/ that approach > either. > >> >> >> Given the great flexibility of Asciidoc and the variety of possible >> extensions/customisations/themes I think it would be better if such >> plugins remain outside the Asciidoc organisation, but with a central >> place for the plugins to be registered and described (a wiki for >> example). This makes it easier for users to find plugins that the >> developer wishes to make available, but does not add to the workload >> of the base project. > > > Personally, I think a wiki is far less sustainable. For as well as Stuart > does keeping the AsciiDoc project page up to date with the list of add-ons, > eventually it will become too much to maintain. Well, thats the point of a wiki, it doesn't take Stuart or a Github committer to update anything. The only manual part is registering the user (to keep out bots and defacers) and that only happens once. Better is the > auto-discoverability approach, where it's easy to find things because the > network links them organically. That's precisely how GitHub ends up being > used. So any repos on github (or anywhere else for that matter) can be linked from the one place, but when the developer of the addon is ready, and not when it is half baked (how to turn people off). Also the wiki is useful for user acquired experience that is related to, but not directly asciidoc, eg how to beat dblatex and fop into line :) At the moment the FAQs are the repository of that knowledge and require website maintainer effort. Cheers Lex -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
