This measure is a vote to officially ratify the Composr CMS constitution.

---

A "yay" vote on this measure indicates:

• Your agreement to stop / remove the Transition Clause (Amendment I) of the constitution if this measure passes
• Your otherwise full agreement to the Composr constitution, and to officially ratify it, as written at https://composr.app/constitution.htm
• Your agreement to officially elect the following members into Composr's Board:
  • Patrick Schmalstig - Core Developer, Site Administrator
  • Christopher Graham - Core Developer, Site Moderator
    • Chris personally requested to be a moderator on the site opposed to administrator
  • Adam Edington - Site Moderator

A 2/3 majority is required to pass this measure as it deals with the Constitution.

---

A "nay" vote indicates you have a disagreement with one or more of the items listed in the Constitution, or with electing one or more of the indicated members to the Board to one or more of the roles indicated for them. Please make a reply to this topic with your disagreements and suggestions.

---

A discussion post to this topic is required when voting.

Honestly, this entire thing has seemed overkill to me from the very first mention of it. It seems like performative self-hamstringing when, at the end of the day, the core developers are the ones who run the project by nature of actively developing and running the project. I understand the image you're wanting to portray on behalf of Composr, but I don't understand why you're so eager to present policies to a very small audience that limit your own power and potential ability to get things done.

I went into this intending to vote "Yay" anyway, because I don't think it really matters. But I came across some specific parts I'd like to point out as being overkill:

Section IV - Voting Requirements
 

• "Effective after the first stable release of Composr CMS version 11, a vote must be conducted for the implementation of feature requests listed on the tracker, or for feature changes to the https:// composr.app homesite, except if one or more of the following conditions apply:"
  • What you're saying here is that implementing feature requests isn't allowed unless the request was sponsored in some way (with money or points). Typically, in open source, "those who do, decide." Why would you tell someone they can't do the work of implementing a feature request unless they get people to pay for it?
  • There's also an exception for if the change "is small and would be implemented as a patch release." This sounds like anything short of a major version bump means it's okay to implement new features, anyway. So why have this entire section at all?
• "A vote must be conducted for the appeal of a member's ban if multiple other members express legitimate concern about the member having been banned."
  • How is "legitimate" defined, and why does it need to be specified that concern must be "legitimate?"
  • Does "multiple other members" mean two or more? If so, why not specify two or more?
• "Votes and their results shall be kept hidden until voting closes."
  • I just noticed this after submitting this post and going to put my "hidden" vote in; posts are public, and posts on voting threads are likely to indicate how someone intends to vote, so I'm not sure how effective this will be.

Section V - Closure
 

• "The measure, or similar measures, shall not be proposed for a re-vote or opened again for at least 3 months following the closing of the votes."
  • You specifically stated you intend to repeat the constitution ratification vote monthly until it's passed. That would be a breach of this line. Whether or not the constitution's taken effect yet, consider that you have a real-world scenario where you've deemed it best to act in a way that contradicts this line already. Is this line optimal?

Section VI - Requirements to Ratify
 

• "This requirement is in no respects to the number of members who vote."
  • I don't know what this sentence means. I tried Googling the term "is in no respects" to see if it meant something different than "in no respect," and it doesn't seem to be a separate phrase (and may be a typo?) Anyway, the previous sentences (the entire rest of the section) stated percentages, so it should go without saying that the number of members who vote is irrelevant.

Section VII - Constitutionality
 

• "No vote shall be conducted on matters regarding the following as they are deemed, by the definition of this section, unconstitutional:
  Anything that violates the rights of members as defined in Article I Section I
  The rights defined in this Constitution are absolute and cannot be infringed."
  • Does this mean Article 1 Section 1 can't be revised with a future amendment? Assuming not, this would be simpler stated as "Anything violating or contradicting the terms of this Constitution (except for constitutional amendments)."

Section I - Rights
 

• Given that Composr is released under an open-source software license, I find it redundant and unnecessary to enumerate rights such as "the right to download and use the Composr CMS software free of charge, subject to the license agreement of Composr CMS" that this constitution wouldn't have the right to restrict, anyway. It seems like the last bullet point is the only one that matters for the constitution, and the rest could be condensed down to simply mention Composr's license.

Article II - Responsibilities
 

• "to contribute to the Composr ecosystem, if they can, in any way(s) they can, when using the software, to support its continued growth and longevity*;"
  • This reads like the license is dependent on contributing back, which of course isn't the case (as noted in the asterisk footnote), but calls into question why this is stated here and phrased this way. It seems more like receiving benefits/voting power/rewards in exchange for giving back is a right (subject to also following the rest of the constitution) more than contributing back is a responsibility.
• "to demonstrate empathy and kindness to all;"
  • I personally take issue with the use of the word "empathy" as a requirement when "empathy" is an emotion that cannot be objectively "demonstrated," as well as with the scope of "to all" when this document should, IMO, only apply when interacting in Composr spaces or in the context of being a Composr community member.
• "to give and gracefully receive constructive criticism and feedback;"
  • Nitpick, but I'd move a word and make this "to gracefully give and receive constructive criticism and feedback;"
• "to accept accountability for any and all mistakes made, to learn from them, to provide apologies and restitution to those impacted, and to come up with an actionable plan to avoid those same mistakes in the future;"
  • This seems like a wide brush. What type of "mistakes" is this line referring to? Coding mistakes, or community/constitution breaches? "Restitution" could be taken to imply some sort of warranty, which probably isn't desired.
• "to approach suggestions and feedback with the mindset of what is best for the overall community opposed to any given individual;"
  • "the overall community opposed to any given individual" should be "the overall community as opposed to any given individual" (emphasis mine).
• While I think the overall social nature of this constitution as you drafted it is fairer and more neutral than the Contributor Covenant itself, I'd personally prefer not to see the Contributor Covenant referenced directly, as it could imply the full text of the original document is also meant to apply. I understand if it needs to be kept in to some extent as a potential copyright issue, though (although I'm unclear on the Covenant's license and it appears they've breached their own licenseat least at some point in the past).
• "to report when someone is violating these responsibilities through the applicable "Report this" links or "Report" buttons, or through [email protected] when using a report link / button is not available."
  • There are certainly plenty of violations of the constitution that would not concern anyone's "equity." I'd prefer that email address be renamed to a more neutral word or phrase, like "[email protected]" or "[email protected]".

Finally, I'm also not a huge fan of how "the Bazaar model" is referenced in the constitution (and in your communications leading up to this point) as some sort of proper noun. I did a web search for "Bazaar software model", and it seems (as I thought) it's simply a metaphorical phrase from a popular book, The Cathedral and the Bazaar. It's not actually defined by any authorities elsewhere. The book simply defines it as "the code is developed over the Internet in view of the public," as opposed to what we might call an "over-the-wall" approach. That's kind of the default assumption for open-source projects, and is evident enough in looking at Composr's development repositories that I don't think it needs to be mentioned in the constitution; but if it does, I'd rather see it actually spelled out than alluded to as if it's an official thing.

With all of that said, seeing as how I've identified both logical questions and a typo or two, I'm respectfully voting "Nay" on this one. I do want to be clear that I'll have no ill will if it passes. Like I already said, I honestly don't think it's going to matter that much.

@jacobgkau I do appreciate that you voted honestly (as I did say vote Nay if you disagree with anything in it) and outlined all of your concerns with the current Constitution. That's why I'm having these votes. This is a process of refining the Constitution to be what the community feels is best fit.

I won't comment specifically on your points until after voting closes as I want to avoid unintentionally biasing anyone's vote. Even if the Constitution passes, at any time, members can propose that a measure be made for further changes to be made to it. But despite this, I still encourage people to only vote Yay if they agree with it as it is written now; if anything substantial needs changed, vote Nay and do what Jacob did by outlining your suggestions.

EDIT: I did also forget to mention, I will leave this topic open until November 1, even though voting closes on October 15. This will give everyone a chance to discuss each other's feedback on the Constitution, especially if it failed and is up for revisions and a re-vote in November.

Looks fine.

Looks good

This looks good!

The Constitution has been ratified. However, suggest edits here. I will likely write a measure for improvements at the beginning of 2026.

 
 
​​​​​​​I apologize for how long it took me to get back with you. Here are my responses to your suggestions on the Constitution:

What you're saying here is that implementing feature requests isn't allowed unless the request was sponsored in some way (with money or points). Typically, in open source, "those who do, decide." Why would you tell someone they can't do the work of implementing a feature request unless they get people to pay for it?

If that is your interpretation, then perhaps I need to edit the wording. What I am saying is this:
- Prior to version 11 becoming stable, features can be implemented by anyone at will.
- Once v11 reaches a stable release, additional features require a simple majority vote from the community to be implemented (similar to how I conducted votes on the three recent measures). There are three exceptions:

• People sponsor the issue with enough points that meet the time demand of implementing the feature (up to the developers to decide based on the value of points to them).
• Someone pays a developer to implement it into Composr CMS.
• The change is small enough to be released as a patch release instead of a minor or major release (see below).

Upon thinking about it, I think exceptions 1 and 2 should probably be removed. In those cases, a vote should still be required to implement it as a core Composr feature. Otherwise, it can be a non-bundled feature instead.

There's also an exception for if the change "is small and would be implemented as a patch release." This sounds like anything short of a major version bump means it's okay to implement new features, anyway. So why have this entire section at all?

I'll give an example. Let's say I decide that an option needs to be split into two different options in the settings. Or, I decide some hard-coded functionality needs an option, so people can control how it works. Or, some functionality needs a slight adjustment to how it works. These are examples of "tiny features" that can be implemented without a vote as a patch release. They are "tweaks" rather than full-blown features. We still call them features, though; anything that isn't a bug fix is a feature.

How is "legitimate" defined, and why does it need to be specified that concern must be "legitimate?"

Good point; we should clarify what "legitimate" means. By "legitimate", I mean whoever banned the member did not provide clear and convincing evidence to them that they violated the Constitution in a manner necessitating a ban.

Does "multiple other members" mean two or more? If so, why not specify two or more?

I'm thinking at least three. However, I think a better route would be for us to get rid of this statement and specify when a member creates a measure about it.

I just noticed this after submitting this post and going to put my "hidden" vote in; posts are public, and posts on voting threads are likely to indicate how someone intends to vote, so I'm not sure how effective this will be.

I cannot make posts private. This happened only on the Constitution one, since I set it to require a reply before voting. Maybe the Constitution should state that measures should never require a reply (to prevent this issue)?

You specifically stated you intend to repeat the constitution ratification vote monthly until it's passed. That would be a breach of this line. Whether or not the constitution's taken effect yet, consider that you have a real-world scenario where you've deemed it best to act in a way that contradicts this line already. Is this line optimal?

That's fair. Thanks for catching that. It's not applicable at this point since the Constitution vote passed. But had it failed, I would have had to delay the next vote to January. I think it is best to keep the rule; we do not want to bother members repeatedly with the same measures over and over again.

I am planning to make another Constitution measure in January. That measure will be to make changes to the Constitution according to the suggestions you and others have made.

I don't know what this sentence means. I tried Googling the term "is in no respects" to see if it meant something different than "in no respect," and it doesn't seem to be a separate phrase (and may be a typo?) Anyway, the previous sentences (the entire rest of the section) stated percentages, so it should go without saying that the number of members who vote is irrelevant.

This is a request Chris Graham made for the Constitution. Initially, I wanted to put in a requirement that a measure had to receive votes from at least 10% of members who were active within the last month; otherwise, it failed regardless of the outcome. Chris did not want any requirement on the number of people who vote on a measure (which is what that is trying to say). It might be better to say that measures only require one vote (or leave it out completely, since a simple majority cannot be achieved without at least one vote anyway).

Does this mean Article 1 Section 1 can't be revised with a future amendment? Assuming not, this would be simpler stated as "Anything violating or contradicting the terms of this Constitution (except for constitutional amendments)."

Yes, Article I, Section I, cannot be revised as it would be unconstitutional. I agree, except I would say Article I, Section I instead of the Constitution (which implies the entire Constitution cannot be revised).

Given that Composr is released under an open-source software license, I find it redundant and unnecessary to enumerate rights such as "the right to download and use the Composr CMS software free of charge, subject to the license agreement of Composr CMS" that this constitution wouldn't have the right to restrict, anyway. It seems like the last bullet point is the only one that matters for the constitution, and the rest could be condensed down to simply mention Composr's license.

I put that in there to establish the following:
- The Composr license agreement cannot ever take away the right for members to download, distribute, fork, or modify the software freely.
- However, you must otherwise follow the terms of the license agreement when doing so.

This reads like the license is dependent on contributing back, which of course isn't the case (as noted in the asterisk footnote), but calls into question why this is stated here and phrased this way. It seems more like receiving benefits/voting power/rewards in exchange for giving back is a right (subject to also following the rest of the constitution) more than contributing back is a responsibility.

I think it is better defined as a privilege. You are right, it is not a responsibility. But it is also not a right; the Board members are not obligated to reward contributions (this would cause problems; we would have to reward every contribution, even useless or malicious ones, and we would have to define what those rewards are, making them unconstitutional to revisions). I will consider moving this into the privileges section for the revision vote.

I personally take issue with the use of the word "empathy" as a requirement when "empathy" is an emotion that cannot be objectively "demonstrated," as well as with the scope of "to all" when this document should, IMO, only apply when interacting in Composr spaces or in the context of being a Composr community member.

I agree. This came from the Contributor's Covenant. And even Chris Graham had an issue with the terminology of empathy. He made a comment on the Covenant about that.

How about understanding and civility instead of empathy and kindness?

Nitpick, but I'd move a word and make this "to gracefully give and receive constructive criticism and feedback;"

Honestly, I'm not even sure about the word gracefully. Maybe we should drop that word entirely?

This seems like a wide brush. What type of "mistakes" is this line referring to? Coding mistakes, or community/constitution breaches? "Restitution" could be taken to imply some sort of warranty, which probably isn't desired.

Any mistakes that cause harm to the community. That would especially include violations of the Constitution. But it can also include coding mistakes (e.g., if I accidentally push a broken release of Composr CMS).

This is also from the Covenant. How about we modify it to this:
to accept accountability for mistakes made that cause harm to the community; (and leave the rest out)

"the overall community opposed to any given individual" should be "the overall community as opposed to any given individual" (emphasis mine).

Noted and agreed.

While I think the overall social nature of this constitution as you drafted it is fairer and more neutral than the Contributor Covenant itself, I'd personally prefer not to see the Contributor Covenant referenced directly, as it could imply the full text of the original document is also meant to apply. I understand if it needs to be kept in to some extent as a potential copyright issue, though (although I'm unclear on the Covenant's license and it appears they've breached their own licenseat least at some point in the past).

As you stated, I have to attribute it as per their Terms. I'll try to make it more clear that the responsibilities are a *modified* version of the Covenant.

There are certainly plenty of violations of the constitution that would not concern anyone's "equity." I'd prefer that email address be renamed to a more neutral word or phrase, like "[email protected]" or "[email protected]".

This is an e-mail address Chris Graham defined. I cannot use abuse because abuse is a standard address for reporting abuse of a company's services (technically, this is a service, but we are talking more on the lines of Code of Conduct violations). I do have a [email protected] address set up, so I will consider changing it to that.

…That's kind of the default assumption for open-source projects, and is evident enough in looking at Composr's development repositories that I don't think it needs to be mentioned in the constitution; but if it does, I'd rather see it actually spelled out than alluded to as if it's an official thing.

Chris Graham used the same terminology as well. The reason we referenced it, despite it being the default assumption of Open Source software, was because Composr CMS v10 did not follow this model (and thus was the exception to the default assumption). Composr v10 was financially backed by Chris' now-closed company, ocProducts, Ltd. Composr v11 is not operating on that model anymore.

Do you think, instead of referencing the Bazaar model Wikipedia article, that I make a new tutorial page outlining Composr's support model (and not call it "Bazaar")? Or, I could just reference the ecosystem page instead.

---

Thank you again for all your feedback, and I look forward to your responses.

Since I was so late getting back with you, I will be leaving this topic open until December 15 now for further discussions.

and others:

I created a draft constitution page for you to review. This is a diff from the current Constitution. Additions are underlined, and removals have a line through them.

Please comment on your thoughts on the changes in this topic.

We will vote on the version of the draft we have in January 2026.

The Composr CMS Constitution

**DRAFT** The Composr CMS Constitution. We, the members of the Composr CMS community, in order to establish the rights and responsibilities of its core develop…

View

Patrick,

I just spent a good hour typing up a reply, but I got a security code error when I attempted to submit, and when I clicked the Back arrow in the Composr interface, my browser gave me a cache miss error. Refreshing from there got me this message:

An internal error occurred (GUID 3f7ca43034b75563aa34c01a4d0411fb). This is usually a software bug and should be reported.

I'm afraid I don't have the energy to re-type all of the points I brought up again right now. I'll try to find time to do it again in the next week or two.

Deleted said

Patrick,

I just spent a good hour typing up a reply, but I got a security code error when I attempted to submit, and when I clicked the Back arrow in the Composr interface, my browser gave me a cache miss error. Refreshing from there got me this message:

An internal error occurred (GUID 3f7ca43034b75563aa34c01a4d0411fb). This is usually a software bug and should be reported.

I'm afraid I don't have the energy to re-type all of the points I brought up again right now. I'll try to find time to do it again in the next week or two.

From “Post #8751”, 11th Nov 2025

Nuts. The autosave feature has been buggy in v11. Check your developer tools; sometimes an autosaved version will exist despite Composr not informing you.

On this site, right-click the page, open developer tools (or inspect). Go to the application tab. Under storage, click local storage. Select composr.app. Look through the keys and values, and you might find one for the post you were typing.

If you feel it's safer, e-mail it to me at [email protected], and I'll put it up on your behalf.

EDIT: Error 3f7ca43034b75563aa34c01a4d0411fb is an expired token hack alert. Composr triggered the application firewall since you tried submitting again with an expired token. The session should have expired before the token did. And you should have received a message about the session. I'll look into this. Maybe I need to trigger a token refresh when you refresh your session from that window.

Amazing. Thank you so much for the local storage trick; it worked. (After trying a few other things like checking for it in my cookies, I'd dumped a huge gcore file overnight trying to get the text back out of the browser tab process's RAM, but I woke up today to it not having worked, so I thought all was lost.)

As an addendum, I also woke up to a Composr on-page pop-up saying my session would expire around 4am (about an hour after I went to sleep), and was logged out, despite having had "Remember me" enabled when I logged in last night. I think you were working on that, so it might be something you're already aware of from comments on some of the news posts.

Here was my original reply:

 

---

Hello Patrick,

Thanks for the detailed response. I'm glad to hear most of my concerns were already on your radar, and that Chris brought some of them up as well.

Firstly, the draft update looks great overall, and I think I'd vote "yes" on it today if it was up for a vote.

Just a couple of thoughts in response to the updates you've drafted so far:
 

• Changing "Some of these have been adapted from the Contributor Covenant" to "This is a modified version of the Contributor Covenant" may not have the desired effect— the new language sounds like it has a stronger tie to the Covenant than the old language, in my opinion. Since the concern is attribution, I might suggest language such as "Some of these were inspired by the Contributor Covenant…", or simply sticking with your original language for now– I think the rest of the changes to the Responsibilities section would largely cover my initial concerns even without any change to the attribution sentence.
• I understand what "minor features" are. What I don't necessarily understand is where you're going to draw the line for a "major feature." Is there some kind of API/ABI compatibility that major versions break that minor versions can't? Does it have to do with the system requirements (e.g. PHP version)? Can I add absolutely anything so long as an in-place upgrade is supported, thus making it a "patch release?"

And a few less actionable, more general thoughts:
 

• I didn't actually dislike having a reply required on the first Constitution vote, but seeing as multiple replies were simply "LGTM," perhaps we're not losing much by codifying that it won't be required.
• I'm honestly not a huge fan of deleting accounts on the homesite after 12 months of inactivity, but I think I'd be able to work with it as a user.
• I still think the "Rights" section could be simplified to just reference the license instead of spelling out four points that are contained within the license, but that may be moot now that it's been ratified, since things can't be removed from that section (although I could argue that it's not a removal of a right if the license grants the same right?) In any case, I don't think the spirit's wrong here, it's just legally unnecessary (in my view).

Finally, I want to circle back to the "Bazaar model" thing since I didn't get a chance to reply to you in a more timely manner about that.

The reason we referenced it, despite it being the default assumption of Open Source software, was because Composr CMS v10 did not follow this model (and thus was the exception to the default assumption). Composr v10 was financially backed by Chris' now-closed company, ocProducts, Ltd. Composr v11 is not operating on that model anymore.

I don't know if I'd agree with your characterization that Bazaar vs. Cathedral is simply about the primary source of funding. Rather, "cathedral-style" development is essentially closed-source in between releases, with only the developers having access to the code and visibility into the work; when a release is made, that's when they publish a static copy of the source code alongside the binary. The "bazaar" model, in my understanding, simply means the code is developed in plain view of the general public, with things like development history and surrounding discussion available for outsiders to view (and optionally participate in). Despite being a sole primary developer, Chris operated this way as long as the project was named Composr, and probably a while before that.

Do you think, instead of referencing the Bazaar model Wikipedia article, that I make a new tutorial page outlining Composr's support model (and not call it "Bazaar")? Or, I could just reference the ecosystem page instead.

I think a tutorial page may be overkill, although it could be helpful to explain the whole points system. As far as the Constitution goes, I think replacing or expanding on "the Bazaar model" with something like this:

Composr development should follow the bazaar-model principle of "release early, release often," where work is organized and performed as publicly as possible.

That would succinctly make it more clear what the intention of that line is. I do want to point out that this is more of a recommendation than a rule, since you can't exactly stop someone from e.g. working on a PR privately for a while before sharing it. But including such a line would allow someone to e.g. raise a concern that a developer or group of developers is hiding too much important discussion by citing the spirit of the line.

Amazing. Thank you so much for the local storage trick; it worked.

I'm glad to hear. I have a tracker issue about this; Composr uses cookies to determine if an auto-save exists in local storage. This does not seem to be working well. I will try to implement a solution that does not use cookies for tracking.

As an addendum, I also woke up to a Composr on-page pop-up saying my session would expire around 4am (about an hour after I went to sleep), and was logged out, despite having had "Remember me" enabled when I logged in last night. I think you were working on that, so it might be something you're already aware of from comments on some of the news posts.

This is actually working as intended. However, I may need to clarify the language around how the "remember me" feature works. The feature does not persistently keep you logged in; this would be very insecure. Instead, it creates a special cookie so that when your session expires, and you get logged out, the cookie will log you back in on the next request automatically. However, because this creates a new session (intentional for security), anything you were doing on the old session is lost.

"Some of these were inspired by the Contributor Covenant…"

I see. You are suggesting that the Constitution should not imply ties to the Covenant. I'll see what works best; using "inspired by" might be the best language.

Is there some kind of API/ABI compatibility that major versions break that minor versions can't?

The language must not be communicating this clearly enough: the difference is not between a minor and major version, but rather a minor version and a patch version. Features that would need to be released on a new minor or major version would require a vote. Features that could be released on a patch version would not require a vote. The differentiating questions would be the following:

• Does this add new functionality to Composr?
• Do other parts of Composr need to be changed for this change to work?
• Is there reasonable potential that non-bundled addons or custom developer code would need to be changed because of this change?

If the developer can answer "no" to all questions, then it can be released as a patch. If any of the above questions answer "yes", then it must be released as a minor version (major version if it breaks compatibility). And in those cases, a vote would be required.

These questions are broad. And that's intentional. Only small tweaks that have a low to no risk of breaking compatibility with other Composr features or with custom code can be released as a patch.

I'm honestly not a huge fan of deleting accounts on the homesite after 12 months of inactivity, but I think I'd be able to work with it as a user.

I feel you. This is non-negotiable to comply with data protection laws and the "right to be forgotten" (But I still need to conduct a vote to require it in; only if the government demands I institute it would I defy the Constitution and immediately implement it in.) It also helps keep composr.app running more efficiently; unused members would get pruned and free up a little space in the database.

I still think the "Rights" section could be simplified to just reference the license instead of spelling out four points that are contained within the license

That makes sense. I worry that by doing so, that would open the door for any future developers to change the Composr license in such a way it removes those rights. By codifying them directly in the Constitution, no one can do that without being in violation of the Constitution.

I don't know if I'd agree with your characterization that Bazaar vs. Cathedral is simply about the primary source of funding…

I see your point. I think what Chris was trying to convey is that Composr CMS was owned (copyrighted) by ocProducts, Ltd. Now, it's copyrighted under his personal name (at least, the portions of the code in which he wrote; I honestly need to think about how we approach copyright in the future). But it has always operated under public development, as you mentioned.

That would succinctly make it more clear what the intention of that line is. I do want to point out that this is more of a recommendation than a rule, since you can't exactly stop someone from e.g. working on a PR privately for a while before sharing it.

I agree. Chris and I discussed "release early, release often" for version 11. Originally, I was able to follow this semi-decently with releases every 2-4 weeks. Now, because Chris is out of the picture, and I am not being funded for Composr work anymore, I cannot meet this quota. Every release requires a run-through of the test suite. And that is very time-consuming. Currently, it is more cost-effective for me to simply keep pushing to git when I make changes, and to cut down on the frequency of official releases. That way, I am spending less time on the test suite overall. That is why releases have been taking 2-4 months now.

The current plan is for me to release 11 beta9, and then 11 beta10 later. At beta10, I will probably stop making any more feature implementations or major changes, and work up to stable (through RC releases) by running through the full test suite piece by piece. Then, once 11 stable is out, I'll have to call it quits there unless other developers hop on board the project or help fund me so I can afford to continue maintaining Composr.

I'm planning to trim the fat on v11 as well by removing some of the non-supported features listed on the maintenance page that are broken and that I cannot afford to spend time maintaining. Composr is currently too big of a system for me to keep maintained as a whole.

Chris and I discussed "release early, release often" for version 11. Originally, I was able to follow this semi-decently with releases every 2-4 weeks. Now… I cannot meet this quota. Every release requires a run-through of the test suite. And that is very time-consuming. Currently, it is more cost-effective for me to simply keep pushing to git when I make changes, and to cut down on the frequency of official releases.

I don't take "release early, release often" to mean releasing a new patch version with the test suite and everything. When you make a commit and push it to a public dev branch on GitLab, that is "releasing early," and when you make public commits between "official releases," that is "releasing often." That is what makes it "bazaar-style." As opposed to waiting until it's entirely finished before publishing 1.0 with an over-the-wall source code dump— that would be the "cathedral."

This is actually working as intended. However, I may need to clarify the language around how the "remember me" feature works. The feature does not persistently keep you logged in; this would be very insecure. Instead, it creates a special cookie so that when your session expires, and you get logged out, the cookie will log you back in on the next request automatically. However, because this creates a new session (intentional for security), anything you were doing on the old session is lost.

I'm not sure if you don't understand or if I don't understand. But I was logged out this morning and had to fill my password from my password manager again to log back in. I don't think I was logged back in automatically. I don't have any of these sort of issues on my v10 site; session management is a solved issue there. This is getting off-topic, though, so we can discuss somewhere else later if need be.

I don't take "release early, release often" to mean releasing a new patch version with the test suite and everything…

Ahh, I get you now. I would have preferred, still, that I could make official releases more often than I am. Version 11 beta9 is going to be the biggest update thus far in the v11 line of releases.

I'm not sure if you don't understand or if I don't understand…

That was me; I did not catch the part about having to log back in manually. That is not intended functionality. The cookie should have logged you back in again on your next request. I have an issue with the tracker for it (right now, I cannot link to it as the tracker is broken, but I am working on a native Composr issue tracker). I think I might have broken some things when I overhauled how cookies work to be more GDPR-compliant.