Below is a pasting of a discussion thread taken from the Habari private message list a while back. Sean (Morydd) had assembled it from his archives of that list.
For the sake of privacy, he has tried to eliminate all names and replace them with letters, using consistent letters for the same individual. Obviously due to what is said, and the fact that our writing voices are known within the community, this isn't a guarantee of anonymity. Posts are numbered, and where a reply is to a post other than the one previous, he has labeled that. Hopefully it's easy enough to follow. The PMC elected to release this discussion to the public mailing list, so that those old points could be reviewed. Owen ----------------------------- [Post: 1] [Author A] I had an epiphany this morning. As long as we're discussing moving SVN to somewhere else (yeah, I know, I'm getting in on the conversation rather late) is it perhaps time to talk about entering the ASF incubator? This would give us SVN, bug tracking, mailing list, web hosting ... as well as all the community, legal, infrastructure, and governance benefits of the ASF. On the negative side, of course, it gives us all that stuff. It's not something to be leapt into casually. I would, of course, be the "champion" of the project. Please don't casually +1 this if you don't understand what I'm talking about. It's not a small thing. === [Post 2] [Author B] Can you give us more information on what this would mean long-term for Habari, both the code and the Community. Are we trading one set of rules (Google's) for another (Apache's). It sounds like they're giving a lot to the project. What are we expected to give back to their community? === [Post 3] [Author A] We've discussed in a sort of "wouldn't it be neat some day" kind of way, since the beginning of the project, being part of The Apache Software Foundation. But it hasn't been done very explicitly on the public list. This hasn't been so much about hiding the fact that we're thinking about it, as about my own personal desire to not have folks think that I'm railroading it through. But, for the most part, I've had positive reactions to the notion. What we get from the community is the stuff I've outlined above. And, yes, there are quite a lot of rules. And in particular, EVERYTHING that we release must be ASL2. We can't release bits of it under other licenses, or dual licenses, or any combination thereof. What we're expected to give back to the ASF is to be part of the community. Exactly what that means will vary greatly from one individual to another, and from one project to another. Some projects are highly involved in the foundation as a whole, such as the HTTP Server project, but this tends to be because we've been there since the beginning. I think it's safe to say that we gain an awful lot, and the cost is low. However, the incubation process tends to be somewhat lengthy. What we have going in our favor is that we've been ASL since day one, and we have a full record of all of our commits from the beginning, so there should be absolutely no surprises in the legal "can we release this code" department. The other aspect of incubation is the health of the community, and the diversity of the community, where "diversity" is defined as "no one company comprises half of the committer base". We're good on these counts, I think. One objection that we're sure to hear is "we've already got one." Roller is a Java-based blogging package that is already an ASF project. Officially, though, "we've already got one" isn't a valid objection. Diversity of projects in the same problem space benefits everyone. But we'll hear the objection. Participation in the ASF community is an evolutionary thing. Over time a project begins to participate in ApacheCon, or become members and so participate in governance. This takes time. === [Post 4] [Author C] Would we have to remove the Blueprint CSS Framework and jQuery? (since both are MIT licensed) Of course, we could ask for a special license, but what are the chances of that happening? I like the idea, but as you said [A], the process is lengthy. Which softwares would be put to our disposal? (e.g: tracker, mailing list, forums?) === [Post 5] [Author A] > > Would we have to remove the Blueprint CSS Framework and jQuery? (since both > > are MIT licensed) I don't actually know. I think that MIT licensed stuff is compatible. I'd have to ask. > > Of course, we could ask for a special license, but what are the chances of > > that happening? Zero. It will never happen. It's not even worth the time to ask. > > I like the idea, but as you said [A], the process is lengthy. > > > > Which softwares would be put to our disposal? (e.g: tracker, mailing list, > > forums?) There are two different bug trackers - bugzilla and jira mailing lists are, I believe, run on ezmlm. forums are not something that are used in any of the ASF projects I'm aware of. The wiki is svnwiki, I think. Anyways, it's svn-backed. === [Post 6] [Author B] One of the things that I saw was that projects in the incubator are not supposed to release without clearance from the Incubator PMC. How does this affect us? === [Post 7] [Author A] This used to be a significant hurdle. These days, it's just a rubber stamp. You say, we want to do a release. The PMC says ok, and you do the release. Given how long it takes us to do a release anyways, I can't imagine that this would be a significant stumbling block. === [Post 8 in reply to Post 3] [Author D] > > We've discussed in a sort of "wouldn't it be neat some day" kind of way, > > since the beginning of the project, being part of The Apache Software > > Foundation. But it hasn't been done very explicitly on the public list. > > This hasn't been so much about hiding the fact that we're thinking about > > it, as about my own personal desire to not have folks think that I'm > > railroading it through. But, for the most part, I've had positive reactions > > to the notion. I think it's worth moving this conversation to -dev and -users, so that we can solicit the community's opinion of the issue. I remember that Doug Stewart once expressed concern about ASF membership, but his opinion seemed poorly informed. I'd like to get other folks' opinions. > > What we get from the community is the stuff I've outlined above. And, yes, > > there are quite a lot of rules. And in particular, EVERYTHING that we > > release must be ASL2. We can't release bits of it under other licenses, or > > dual licenses, or any combination thereof. We currently use MIT licensed code from other projects. This will need clarification. I am not keen on reinventing all of these libraries. > > One objection that we're sure to hear is "we've already got one." Roller is > > a Java-based blogging package that is already an ASF project. Officially, > > though, "we've already got one" isn't a valid objection. Diversity of > > projects in the same problem space benefits everyone. But we'll hear the > > objection. Roller seems to target a different user than Habari. I'm not overly worried about this complaint. > > Participation in the ASF community is an evolutionary thing. Over time a > > project begins to participate in ApacheCon, or become members and so > > participate in governance. This takes time. In a general sense, I'm +1 on the idea of applying for incubation. I think it will help provide a greater sense of legitimacy to our project with those people who still see us as a reaction to WordPress. Moreover, participation the ASF will (or should) demonstrate that our "cabal" is not a private clique, nor that we are subject to the same long-term governance problems that other projects face. I am worried about the licensing issue, particularly; and I'm marginally concerned about whether or not we can ever actually graduate from incubation. Are we obligated to use ASF-provided resources? Certainly we'd want their SVN and mailing lists; but do we need to use their wiki? Could we continue to use the MediaWiki installation on habariproject.org? Does the ASF provide us with adequate web and database capacity such that we could run our own forum? I think it's worth moving this conversation to -dev and -users, so that we can solicit the community's opinion of the issue. I remember that Doug Stewart once expressed concern about ASF membership, but his opinion seemed poorly informed. I'd like to get other folks' opinions. We currently use MIT licensed code from other projects. This will need clarification. I am not keen on reinventing all of these libraries. === [Post 9] [Author A] > > I think it's worth moving this conversation to -dev and -users, so that we > > can solicit the community's opinion of the issue. I remember that Doug > > Stewart once expressed concern about ASF membership, but his opinion seemed > > poorly informed. I'd like to get other folks' opinions. +1, I think. And, we do absolutely need the buy-in of the community before this could work. > > I am worried about the licensing issue, particularly; and I'm marginally > > concerned about whether or not we can ever actually graduate from > > incubation. Things do eventually graduate. The first stuff that went through had a very hard time of it, but from what I'm told, the kinks have been worked out and things are much more smooth than they once were. > > Are we obligated to use ASF-provided resources? Certainly we'd want their > > SVN and mailing lists; but do we need to use their wiki? Could we continue > > to use the MediaWiki installation on habariproject.org? Does the ASF > > provide us with adequate web and database capacity such that we could run > > our own forum? We are obliged to use ASF resources, unless there is a compelling reason to use some resource that the ASF does not provide. There is generally resistance to projects running their own infra off of the ASF hardware, but I'm not sure 1) the reasons given for this or 2) the resolutions to those situations. I have not kept up on the incubator mailing list for the last year or so. These are questions that we would need to ask prior to committing to this course of action. === [Post 10] [Author B] I propose a vote on presenting this to -user and -dev (probably most sensible to announce it on both, but ask that discussion be on one or the other.) I think if the PMC doesn't have enough support to carry it, there's no point in presenting it to the community at large. However this is much too large a decision to not get feedback sooner rather than later. For the record, I'm +1 on moving the discussion to -user/-dev.If desired, I'll write up a summary of what we've discussed so far and submit a draft to this list for presentation to the public lists. === [Post 11] [Author D] I'm +1 on taking this discussion to the public lists. === [Post 12] [Author E] +1 as well on taking it to the list, as well as [B] writing something up for presentation. === [Post 13] [Author F] +1 to bringing it to the list, also. From what I've read, I think there are quite a few good reasons to join, and I'm having a hard time seeing any reasons -not- to join. === [Post 14 in reply to post 10] [Author G] I too am +1 for taking this to discussion groups, though I'd suggest one list or the other, so the discussion doesn't get fractioned. I think moving it to a list would allow for better understanding of the process for everyone, as new questions others might not think to ask are brought up. === [Post 15] [Author A] It belongs on the -dev list, not on the -users list. === [Post 16 in reply to Post 14] [Author H] Go ahead and say something on the public lists if you like, but I thought I would mention now that while I'm not actively against it, I'm currently leery of the result of Apache incubation. Should I hold my thoughts until this hits the public list, or do you want to hear them now so I can be persuaded to agree with the rest of the PMC? === [Post 17] [Author D] Spill the beans, [H]. === [Post 18] [Author H] I'll preface this with the thought that bringing Habari under the ASF umbrella has been in my thoughts since we started the project, and I've always considered it a good idea. Also, as I said before, I'm not against the idea, but I think we really need to clarify some issues before we go through the effort. It may be simply an issue of me not understanding how Apache will be involved, but I think it's important to know the answer to those questions before continuing, if not for our own peace of mind, then to be able to answer questions when our community poses them to us when this goes public. The original suggestion in this thread was that since we are considering abandoning Google Code for something that works with our project better, we ought to consider Apache incubation so that we can make use of those resources. This is a good idea, but it leaves me asking whether we would be joining Apache for the tools they offer or for the community/license/support. Looking at the infrastructure available as an Apache podling, I must say that I'm not impressed by the tools. We like to say that we're using the cutting edge technology for a reason, and I do see some reason to stick with solid development tools, but I don't see anything special in what the ASF offers in this regard. For example, to what extent will we be able to integrate our site with our subversion repositories? How will the repos on ASF servers be affected by our desire for -contribs section in the main repository? What tools will be be forced to use because they are the ASF-provided ones, and will we be caught in a situation like we already are in Google Code, where the public, unregistered/unauthenticate community is limited in participation? To what extent will our branding and promotion (including the habariproject.org site) be affected by what Apache requires? Will the ASF infrastructure allow us to follow through on the unique user-support ideas that we've discussed? I'm already disenchanted with what few notions I've read concerning the involvement of the ASF in the project. The incubator PMC needs to approve releases? Rubber stamp or not, it seems to me that Habari is not their project (they've earned no merit in our community) to be making even rubber-stamp decisions about our software. I suppose that this is a process to prevent projects from being released with the Apache name on them without approval, but I gotta say, I don't really like the sound of "Apache Habari" either, which is a branding requirement. There are a couple of other simple technical quibbles. First, we never really formalized our voting procedure for issues; what requires a vote, and what is required to pass a vote. I think it's actually better that we *don't* do this if we want to incubate, because I foresee conflict with how we would prefer to vote and the Apache model of voting (at least in the area of number of required votes). As with building our software from the ground up where we've had the opportunity to eschew the chaff of legacy considerations, we also see how a voting system might be enacted and what might best fit our community, rather than what Apache provides. That's not to say that Apache isn't good or doesn't work, just that if we don't go the ASF incubator route, that enables us to have the opportunity to take the best parts of it and own it, rather than take on a process that has governed Apache for a while and could be difficult to react to change. Also, I think that our project is not quite technically mature enough to start with incubation. We're focusing much of our effort now on creating a working system. Adjusting our priorities to fit any needs that ASF incubation might require would be a distraction to that goal right now. One of the great benefits of ASF incubation would presumably be greater exposure to people who could help complete the software, which might offset that, but that brings me to my next point about having the correct people for our project. We've been very inclusive, I think, but only of people who understand the value of our project and are willing to continue those concepts with their contributions. So far, this has worked out well for us. I wonder if we're missing out on a larger community, one that might be available to us by Apache incubation, but I find I don't really care about that right now -- I like the way things are, I like the direction we've been heading, I like the rate at which our membership/ community has been growing without Apache, and I think that going through the incubation process isn't going to be as beneficial to us as we originally thought when we started out, perhaps not even enough to be worth doing it. I've been operating under an assumption that having the Apache name attached to our project would be a positive thing, and I still think that the Apache name imparts prestige, but in really thinking about why we would want to do this I can't come up with any other reason that I find appealing. Looking through the incubator documentation online, I see that most of it is about Apache bringing in projects that it wants to include, and not about why a project might want to be a part of Apache - the real benefits to a project. So why is it really that would we do this? Anyway, I can probably be convinced out of any of this fairly easily, but I didn't see anyone making many significant concern known before going to the public lists with this, and I think that if enough of our own committers really consider what this means, what's entailed, and what benefits we expect to get out of it, we may be able to save ourselves some trouble figuring out that we don't want this later down the line. Or I may be totally nuts, but I still think it's important to think about this rather than say +1 to an idea that sounds good on the surface. === [Post 19] [Author D] > > The original suggestion in this thread was that since we are considering > > abandoning Google Code for something that works with our project better, we > > ought to consider Apache incubation so that we can make use of those > > resources. This is a good idea, but it leaves me asking whether we would > > be joining Apache for the tools they offer or for the > > community/license/support. Licensing and legal support are non-trivial. I like the idea of an organization with sufficiently more experience than we have being stewards of the legal status of our project. > > To what extent will our branding and promotion (including the > > habariproject.org site) be affected by what Apache requires? Good question. The Incubation documents say we need to use the URL http://incubator.apache.org/habari, and store our website in SVN. It's not entirely clear whether we can use the Incubator site for development-specific info, while still using habariproject.org for our "public" interface to end users. > > I'm already disenchanted with what few notions I've read concerning the > > involvement of the ASF in the project. The incubator PMC needs to approve > > releases? Rubber stamp or not, it seems to me that Habari is not their > > project (they've earned no merit in our community) to be making even > > rubber-stamp decisions about our software. I suppose that this is a > > process to prevent projects from being released with the Apache name on > > them without approval, but I gotta say, I don't really like the sound of > > "Apache Habari" either, which is a branding requirement. I don't object to the Incubation group approving our releases during incubation. It's a reasonable measure of due-diligence and oversight for a project of (originally) unknown quality. Apache Habari does not have a lot of ring to it, though. > > I've been operating under an assumption that having the Apache name > > attached to our project would be a positive thing, and I still think that > > the Apache name imparts prestige, but in really thinking about why we would > > want to do this I can't come up with any other reason that I find > > appealing. Looking through the incubator documentation online, I see that > > most of it is about Apache bringing in projects that it wants to include, > > and not about why a project might want to be a part of Apache - the real > > benefits to a project. So why is it really that would we do this? We've managed to bootstrap our project pretty well, and I think we have a good foundation upon which to build. We don't, strictly speaking, need to go through the Apache Incubator. I still think it's a good idea to consider, though. It shields the project legally from code contributions which we ought not accept. It provides some formal body of stability for governance, which we currently lack. If we all have a major falling out, the project could languish. Is that sufficient to justify incubation? I honestly don't know. === [Post 20] [Author H] > > Licensing and legal support are non-trivial. I like the idea of an > > organization with sufficiently more experience than we have being stewards > > of the legal status of our project. I agree that these are non-trivial, and find it astonishing that there isn't an organization devoted to that aspect of free software in the general sense without trying to push their own licensing agenda. > > I don't object to the Incubation group approving our releases during > > incubation. It's a reasonable measure of due-diligence and oversight for a > > project of (originally) unknown quality. I would feel fine about that if that was the case, but whether it's how I imagine it or not, I do imagine a guy standing at the door of our project checking the stamps on all the boxes going out without actually looking in the room (or box) to see what's going on. What's the point? > > I still think it's a good idea to consider, though. It shields the project > > legally from code contributions which we ought not accept. It provides > > some formal body of stability for governance, which we currently lack. If > > we all have a major falling out, the project could languish. > > Is that sufficient to justify incubation? I honestly don't know. That's the question I've been asking myself about this process. Is there some way we can better address Habari's needs than throwing in with Apache? I think we should consider/research that, too, if possible. === [Post 21] [Author A] > > I agree that these are non-trivial, and find it astonishing that there > > isn't an organization devoted to that aspect of free software in the > > general sense without trying to push their own licensing agenda. This is a simple matter of pragmatism. When you have a standard license, your law people learn how to deal with it. When you have 20 licenses, they don't. > > I would feel fine about that if that was the case, but whether it's how I > > imagine it or not, I do imagine a guy standing at the door of our project > > checking the stamps on all the boxes going out without actually looking in > > the room (or box) to see what's going on. What's the point? I'm not able to figure out the correlation between your box analogy and approving releases. The folks who would be approving a release would be following all the mailing lists on the project. What I'm hearing you, and perhaps other, say, contains a lot of "us and them" language. If we were to enter the incubator, it would all be "us". > > That's the question I've been asking myself about this process. Is there > > some way we can better address Habari's needs than throwing in with Apache? > > I think we should consider/research that, too, if possible. Well, clearly I'm very biased -- I think that the ASF is a great place, full of great people. It gives us more direct access to experts in a variety of fields, like HTTP, Atom, SVN, and a variety of other things, and it gives us their attention. And being part of Apache gives us a degree of respect that we don't have now. I suppose, however, that I might should stay out of the conversation, given that I'm 1) extremely biased, and 2) haven't exactly been an active participant, and so have a lot less to gain/lose by such a move. === [Post 22] [Author H] > > This is a simple matter of pragmatism. When you have a standard license, > > your law people learn how to deal with it. When you have 20 licenses, they > > don't. If the case is that we require ASL on every piece of source, then being a part of Apache will not happen. jQuery is not ASL, and rewriting it or using some other solution defeats the purpose of having selected it over those other solutions in the first place. This is the case with the few non-ASL libraries that we have. Given the quantity of libraries we've already written from scratch to comply with the ASL, I find it likely that these are not already ASL-licensed libraries for good reason. > > I'm not able to figure out the correlation between your box analogy and > > approving releases. The folks who would be approving a release would be > > following all the mailing lists on the project. If it's a rubber stamp process, then what's the point? >> > > What I'm hearing you, and perhaps other, say, contains a lot of "us and >> > > them" language. If we were to enter the incubator, it would all be "us". >From http://incubator.apache.org/guides/releasemanagement.html : "All releases by podlings must be approved by the TODO: link IPMC. The conventional process is for the podling to flow the usual Apache process (including TODO: link release vote) and then call for a IPMC VOTE on the TODO: link general incubator list." It seems to me that the Habari PMC is not who decides whether our own software is released in this situation. And as I've said, it seems counter-intuitive to hand release controls over to anyone who has not demonstrated the merit of them that the ASF espouses. > > One more remark. Incubation isn't about technical maturity. It's about two > > things: 1) health of the community - ie, can the community sustain itself. > > I think we're very solid on this. 2) legality of release. We've been ASL2 > > from day one, and we have a complete commit/contribution history, so we've > > got this one solid too. I was not talking about whether our code is good enough to be accepted for incubation. Rather, I was talking about whether our continued, human-limited development efforts are better directed at completing the software than working on adhering to Apache requirements. There are also hints in the incubation documentation that a certain number of releases might be a qualifier for acceptance, though they're added somewhat as a question in a footnote in the regretfully incomplete incubator documentation. === [Post 23] [Author A] > > If the case is that we require ASL on every piece of source, then being a > > part of Apache will not happen. jQuery is not ASL, and rewriting it or > > using some other solution defeats the purpose of having selected it over > > those other solutions in the first place. This is the case with the few > > non-ASL libraries that we have. Given the quantity of libraries we've > > already written from scratch to comply with the ASL, I find it likely that > > these are not already ASL-licensed libraries for good reason. I'm reasonably certain that many, many ASF projects use third-party libraries which are not ASL licensed. > > If it's a rubber stamp process, then what's the point? I'm not sure if you're being intentionally argumentative to make a point here. Perhaps I can rephrase. The IPMC will not unreasonably refuse to allow a release. So perhaps "rubber stamp" was a loaded phrase that I should not have used. Better? > > From http://incubator.apache.org/guides/releasemanagement.html : "All > > releases by podlings must be approved by the TODO: link IPMC. The > > conventional process is for the podling to flow the usual Apache process > > (including TODO: link release vote) and then call for a IPMC VOTE on the > > TODO: link general incubator list." > > It seems to me that the Habari PMC is not who decides whether our own > > software is released in this situation. And as I've said, it seems > > counter-intuitive to hand release controls over to anyone who has not > > demonstrated the merit of them that the ASF espouses. This is perhaps the most reasonable objection to the Incubator that I've ever heard. I have no response to it, other than that the ASF uses the Incubator to shield itself from accepting projects which would expose it (the ASF) to legal risks, and so this is a reasonable precaution. From the perspective of us, Habari, we would be enduring a temporary inconvenience in exchange for a number of very real benefits. If those benefits are deemed to not be worth the sacrifices, then, by all means, let's pursue a different road. > > There are also hints in the incubation documentation that a certain number > > of releases might be a qualifier for acceptance, though they're added > > somewhat as a question in a footnote in the regretfully incomplete > > incubator documentation. I've not encountered that as an enforced requirement, but, as I said, I haven't been following the incubator mailing lists very closely for the last year or so. === [Post 24] [Author H] > > The IPMC will not unreasonably refuse to allow a release. So perhaps > > "rubber stamp" was a loaded phrase that I should not have used. Better? To phrase a better question: What conditions would cause the IPMC to permit or refuse a release? It seems difficult to me that they could audit the code for "Apacheness" yet not be as involved as a Habari PMC, and so I am unable to reason out these conditions. > > From the perspective of us, Habari, we would be enduring a temporary > > inconvenience in exchange for a number of very real benefits. If those > > benefits are deemed to not be worth the sacrifices, then, by all means, > > let's pursue a different road. I remain unsure that the benefits are worth the sacrifices. It's frustrating that I could find little in the incubator documentation about why a project would want to go through the process, and what changes it means a project will undergo. Surely someone has had to convince some other PMC member that it was a good idea for their project, or am I the only boneheaded holdout in all of Apache incubator history? Is it possible to get a review before entering incubation? Maybe talk with someone from the IPMC about these concerns? === [Post 25] [Author A] > > Is it possible to get a review before entering incubation? Maybe talk with > > someone from the IPMC about these concerns? Not only possible but expected, I believe. I can arrange such a conversation if you like. === [Post 26 in reply to Post 18] [Author A] > > Also, I think that our project is not quite technically mature enough to > > start with incubation. One more remark. Incubation isn't about technical maturity. It's about two things: 1) health of the community - ie, can the community sustain itself. I think we're very solid on this. 2) legality of release. We've been ASL2 from day one, and we have a complete commit/ contribution history, so we've got this one solid too. === [Post 27 in reply to Post 16] [Author A] > > Should I hold my thoughts until this hits the public list, or do you want > > to hear them now so I can be persuaded to agree with the rest of the PMC? I'd like to hear them now. I tend to think that opening this discussion to the peanut gallery before we have consensus here is likely to be a huge waste of time. Please speak up. === [Post 28 in reply to Post 1] [Author J] +1 on taking discussion to the public lists. I haven't any input on the whole debate though - I really don't know enough about it to have an opinion....\ === [Post 29] [Author K] Same for me, I don't have enough understanding of it but +1 take it to public mailing list for discussion. === [Post 30] [Author B] Here is a draft post for -user and -dev. I feel (for reason with any basis in fact) that most of -dev is also subscribed to -user, so it would be appropriate to make that list the primary discussion point for this. Please let me know if there is anything I can add or should remove from this: There has been some discussion in the past of applying Habari for inclusion in the Apache Incubator. As we are currently looking at moving away from Google Code, now would be an appropriate time to make that transition. You can read more about the Apache Incubator at http://incubator.apache.org/ The PMC has discussed this issue, and we believe that we need the input of the Habari Community as a whole to continue that discussion, let alone come to a decision. There are advantages and disadvantages to this move, and it will require some careful examination of the long- term goals and structure of the Habari Project. Advantages include having a legal entity "own" the code, to protect the project; guidance in managing the community, including the userbase, the developers and the PMC; as well as having the support and resources of the ASF to draw on as we grow. Disadvantages include having to shift our existing structure (svn, issues, ect.) to the ASF system, being formally bound to the Apache License, and requiring approval from the Incubator PMC to release. Please read the information on the Apache Incubator page, and ask any questions you may have so that we are able to come to a well-informed community consensus on this issue. In the interest of keeping this discussion centralized, please make any responses to the habari-user mailing list. === [Post 31] [Author D] The draft looks fine, and nails all the salient points. I encourage cross-posting this to -dev and -user, just to be safe. Stipulate that all discussion on -dev of this issue is off-topic and won't get a reply. === [Post 32] [Author A] > > I encourage cross-posting this to -dev and -user, just to be safe. > > Stipulate that all discussion on -dev of this issue is off-topic and won't > > get a reply. Seems backwards to me - this is a discussion for developers, not for end-users - but I'll defer. I don't suppose it matters all that much which list it's on. === [Post 33] [Author D] It seems to me a discussion for the community of interested participants, whether they're developers or not. We'll be expecting end users to file bugs on whatever issue tracker we use. It strikes me as a nice thing to do to permit them to express an opinion on how that ultimately works. === [Post 34] [Author C] +1 to go public --~--~---------~--~----~------------~-------~--~----~ 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/habari-users -~----------~----~----~----~------~----~------~--~---
