Really interesting discussion, how to scale and manage an OSS project. I don't have strong opinions beyond wanting to keep the AsciiDoc "core" stable (i.e. primarily in maintenance mode).
These posts I made on older threads are still relevant (in fact I've just converted the wordpress backend to a plugin and moved it to the blogpost project where it belongs): ``The primary motivation for the plugin architecture was to enable filters and backends to be implemented as plugins. The idea is to decouple the AsciiDoc core from backends and filters. The HTML and DocBook backends (and successors) will stay in the core distribution but I envisage that all new backends will be implemented as plugins. From a maintenance standpoint it's the only sane way forward,'' ``At it's core asciidoc is a tool for generating HTML and DocBook output and in my opinion it already has to many backends in the distribution (my primary motivation for the recent plugins, themes and filters support).'' Cheers, Stuart On 07/12/12 16:21, Lex Trotman wrote: > [...] >>> 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. >> > > I think the difference is your experience is in web stuff, where > everything is dynamic and online, mine is in thingspace where code and > docs need to also go offline, code in standalone machines and docs > even in dead tree format :) > >> 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 > > Which is fine if your customers are developers, they can be expected > to understand such things, but Asciidoc is used by lots of > non-developers, and they don't see or understand such subtleties. > > In fact my experience on Geany (an IDE, and therefore the users are > mostly developers of some type) is that the same is often true for > developers too :( > > >> 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. > > And again Asciidoc non-developers *can't* do that by themselves. > >> >> 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. > > Geany has been forced to deprecate and remove several plugins when > they became incompatible due to lack of maintenance, and that got some > howls :) > > If plugins are suitably important and suitable quality then maybe they > can be taken under the project wing, so long as it gets some more > developers beyond Stuart. I don't have guaranteed time to do more > than answer stuff on the ML. > > It is very important for something like Asciidoc which is very mature > and needs to maintain backward compatibility so that archived > documents can continue to be processed. Plugins that a document needs > must be as stable and backward compatible as the base application. > [...] >>> 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. > > That better, I was somewhat perplexed by the original reply :) > >> >> 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. > > Sure the protected front page of the wiki should have all the boilerplate etc. > >> >>> >>> >>> 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). >> > > Yes, that has always been a problem, how to gain maturity without > exposing too many users to underdeveloped code. > >>> >>> >>> 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. > > Havn't used the ones in github, but it appears that it only works > locally, thats not too good for non-developers submissions. Needs to > use git, have ruby, and doesn't work on windows. It should be able to > be editied with an online editor so there are no requirements on the > client except a browser. > > Cheers > Lex > >> >> -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. > -- 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.
