inline... On Thu, Dec 6, 2012 at 2:39 AM, Lex Trotman <[email protected]> wrote:
> > > 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. > That's unfortunate. It will be interesting to see if it suits the needs of AsciiDoc. They offer both Python 2 and Python 3, so that's promising. > > >> 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 the definition of what is "part of" a project is evolving. I can only speak from experience. In the Arquillian "organization" on github, we have a few modules / add-ons that have been idle for awhile. The commit history tells the story that the people need to know...when it was last updated and by whom, and if there are any pull requests open. If the visitor wants to see it active again, they are empowered to send a pull request (or ping on an existing one). That could trigger a variety of activity. If it doesn't, the visitor can escalate to the mailinglist to plead for someone to attend to it or to make them the new maintainer. If all those options fail, they can just start promoting their own fork...and as a community we could decide how to go from there. In essence, I'm saying that rather than us (on behalf of the AsciiDoc project) saying that some add-on is sanctioned, we let the facts (commits) speak for themselves. I've never had anyone come to me and say that they were mad because an add-on to Arquillian has become idle. If they were mad, they could fix it themselves. That's open source just doing what open source does best. > > > 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. > I realized when I read your response that I was thinking one thing and typing another. I meant to say that it *should* be a wiki page rather than a file managed by a single person. It's when the responsibility falls on a single person's shoulders that it cannot be scalable. So ignore what I said and +1 to the wiki page listing these add-ons. For what it's worth, we could add a disclaimer that we don't sanction the extensions, we are just listing them to make people informed. I think they become "sanctioned" when they become part of the AsciiDoc distribution. But remember, this is all just community-supported, so I'm using "sanctioned" very loosely here. > > 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). > Absolutely...we don't just pull in code without reviewing what state it is in first. For instance, take my bootstrap-docs backend. That is still very much a prototype and I wouldn't expect that to be put under the asciidoc organization yet. Once it's been vetted a bit more and users start giving it the thumbs up, then it would be time to "promote" it to the organization to get more visibility (and to be more useful to community). > > 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. > +1 Having worked with the JDF team to create their docs in AsciiDoc, I know they accumulated a number of tips to share. Having a wiki for that information would be great! I happen to like the wiki on GitHub because it is, itself, a git repository and the documents can be written in AsciiDoc. That seems to be right in our direction...and there is no lock-in since the wiki can easily be migrated somewhere else. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- 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.
